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Abstract 

Quantum  Key  Distribution  (QKD)  is  a  revolutionary  security  technology  that 
exploits  the  laws  of  quantum  mechanics  to  achieve  information-theoretical  secure  key 
exchange.  QKD  is  suitable  for  use  in  applications  that  require  high  security  such  as  those 
found  in  certain  commercial,  governmental,  and  military  domains.  As  QKD  is  a  new 
technology,  there  is  a  need  to  develop  a  robust  quantum  communication  modeling  and 
simulation  framework  to  support  the  analysis  of  QKD  systems. 

This  dissertation  presents  conceptual  modeling  QKD  system  components  using 
the  Discrete  Event  System  Specification  (DEVS)  formalism  to  assure  the  component 
models  are  provably  composable  and  exhibit  temporal  behavior  independent  of  the 
simulation  environment.  These  attributes  enable  users  to  assemble  and  simulate  any 
collection  of  compatible  components  to  represent  QKD  system  architectures.  The 
developed  models  demonstrate  closure  under  coupling  and  exhibit  behavior  suitable  for 
the  intended  analytic  purpose,  thus  improving  the  validity  of  the  simulation. 

This  research  contributes  to  the  validity  of  the  QKD  simulation,  increasing 
developer  and  user  confidence  in  the  correctness  of  the  models  and  providing  a 
composable,  canonical  basis  for  performance  analysis  efforts.  The  research  supports  the 
efficient  modeling,  simulation,  and  analysis  of  QKD  systems  when  evaluating  existing 
systems  or  developing  next  generation  QKD  cryptographic  systems. 
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CONCEPTUAL  MODELING  OF  A  QUANTUM  KEY  DISTRIBUTION 
SIMULATION  FRAMEWORK  USING  THE  DISCRETE  EVENT  SYSTEM 

SPECIFICATION 

1.  Introduction 

1.1  The  Need  for  Secure  Communications 

Cryptography,  the  practice  and  study  of  techniques  for  securing 
communications  between  two  authorized  parties  in  the  presence  of  one  or  more 
unauthorized  parties,  is  the  centerpiece  of  a  centuries  old  battle  between  code  maker  and 
code  breaker  (Singh,  1999).  Historically,  only  financial,  government,  and  military  entities 
used  cryptography;  but  today  much  of  modern  society  depends  on  cryptography  to 
provide  security  services  including  confidentiality,  integrity,  authentication,  and  non¬ 
repudiation  (Barker,  Barker,  &  Lee,  2005).  While  there  are  many  types  of  cryptography, 
only  the  One-Time-Pad  (OTP)  symmetric  key  algorithm  is  “information-theoretically 
secure”  (C.  E.  Shannon,  1948;  C.  E.  Shannon,  1949).  All  other  forms  of  cryptography  are 
breakable  if  the  adversary  has  enough  cipher  text,  computational  resources,  and  time 
(Schneier,  1995),  either  by  finding  flaws  in  the  encryption  algorithm  or  decoding  the 
cipher  text.  Despite  its  strength,  the  OTP  is  not  in  common  use  because  of  the  large 
amount  of  secret  key  material  required  for  its  proper  use  (i.e.  random  generation,  length 
equal  to  the  message,  and  single  use)(Bellovin,  2011).  These  requirements  impose 
significant  limitations  on  use  of  the  OTP  in  most  applications  due  the  costs  involved  with 
secure  key  generation  and  distribution. 

Quantum  Key  Distribution  (QKD)  is  a  technology  that  offers  the  means  for  two 
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geographically  separated  parties  to  generate  a  shared  secret  key  (Grimaila,  Morris,  & 
Hodson,  2012).  QKD  is  unique  in  its  ability  to  detect  any  eavesdropping  on  the  key 
exchange,  assuring  the  secrecy  of  the  key.  This  is  possible  due  to  the  fundamental  laws  of 
quantum  mechanics  which  ensures  eavesdropping  on  the  quantum  channel  introduces 
detectable  errors.  QKD  enables  an  “unconditionally  secure”  cryptosystem  when  paired 
with  the  OTP. 


1.2  Quantum  Key  Distribution  (QKD) 

In  1984,  Charles  Bennett  and  Gilles  Brassard  proposed  the  first  QKD  protocol, 
BB84,  for  secure  communication  (Bennett  and  Brassard,  1984).  The  goal  of  the  system  is 
to  provide  perfect  secrecy  during  key  distribution.  Using  a  QKD  protocol,  a  sender  and 
receiver  exchange  an  unconditionally  secure  secret  key  by  leveraging  properties  of 
quantum  mechanics.  QKD  enables  two  parties  to  “grow”  a  shared  secret  key  without 
placing  any  limits  on  an  adversary’s  computational  power  and  can  detect  the  presence  of 
any  third-party  eavesdropping  on  the  key  exchange.  Because  of  the  laws  of  quantum 
mechanics,  any  third-party  eavesdropping  on  the  key  exchange  will  introduce  detectable 
errors.  If  the  errors  are  below  a  defined  threshold,  the  two  parties  involved  in  the  key 
exchange  can  distill  an  unconditionally  secure  key.  QKD  provides  a  potential  solution  to 
the  key  distribution  problem  by  enabling  two  parties  connected  by  a  quantum  channel  to 
continuously  produce  an  unconditionally  secure  shared  secret  key,  or  decide  not  to  use  a 
key  if  detecting  an  eavesdropper. 
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1.3  The  Need  for  QKD  Simulation 

QKD  is  a  developing  technology  and  not  thoroughly  studied  from  a  systems-level 
perspective.  QKD  systems  contain  non-ideal  components  that  differ,  sometimes 
significantly,  from  the  ideal  components  specified  during  the  original  conceptual  system 
design.  Therefore,  there  is  a  need  to  develop  an  efficient  integrated  modeling  and 
simulation  capability  to  understand  the  impact  non-ideal  components  have  on  the 
performance  and  security  of  different  QKD  system  architectures. 

Because  of  the  limits  of  technology,  it  is  impossible  to  build  the  ideal  QKD 
system  described  in  theory  (Scarani  et  ah,  2009).  Therefore,  each  QKD  implementation  is 
only  an  approximation  of  the  ideal  apparatus  described  in  theory.  Therefore,  our  research 
effort  focuses  on  the  development  of  a  QKD  modeling  and  simulation  framework  that 
includes  system  implementation  non-idealities  in  the  system  analysis  to  better  understand 
their  impact  on  overall  system  performance  and  security. 

There  exist  few  QKD  simulations  beyond  those  that  model  specific  hardware  or 
situations.  An  example  is  the  Austrian  Institute  of  Technology’s  AIT  QKD  Software 
project  (Austrian  Institute  of  Technology,  2014)  that  attempts  to  model  an  entire  QKD 
network  but  focuses  on  one  QKD  hardware  type  (entanglement).  An  extensive  literature 
search  over  several  years  revealed  no  other  multi-technology  system-level  QKD 
modeling  &  simulation  (M&S)  efforts. 

To  address  this  shortcoming,  a  research  team  at  the  Air  Force  Institute  of 
Technology  developed  a  modular  simulation  framework,  named  qkdX,  which  provides 
users  the  capability  to  model  efficiently,  simulate,  and  study  QKD  system  architectures. 
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This  simulation  capability  provides  hybrid  functionality  as  it  abstracts  continuous-time 
QKD  system  signals  (e.g.,  electrical  signals  and  optical  pulses)  into  a  representation 
suitable  as  events  in  a  Discrete  Event  Simulation  (DES)  environment  (Morris,  Hodson, 
Grimaila,  Jacques,  &  Baumgartner,  2014). 

1.4  Problem  Description 

Just  as  in  the  early  days  of  computing,  each  QKD  system,  whether  commercial  or 
research,  is  a  unique  implementation  based  on  the  theory  and  principles  of  QKD  using 
currently  available  components,  protocols,  and  technology.  As  there  are  no  widely 
accepted  security  and  performance  standards  for  evaluating  QKD  systems,  each  system 
designer  architects  their  system  based  on  their  own  views  and  needs.  The  ability  to  model 
accurately  and  simulate  QKD  systems  at  an  appropriate  abstraction  level  is  an  essential 
capability  necessary  for  analysis  of  current  and  next  generation  QKD  cryptographic 
systems. 

Currently,  there  exists  no  efficient  means  of  modeling,  simulating,  and  analyzing 
different  QKD  systems.  There  is  a  need  to  develop  a  flexible,  extendable,  quantum 
communication  modeling  and  simulation  analysis  framework  that  take  advantage  of  all 
the  best  practices  in  modeling,  simulation,  and  analysis  and  model  QKD  systems  at  an 
appropriate  detail  level  to  estimate  system-level  attributes  in  areas  such  as  security, 
performance,  and  cost. 

Best  practices  in  modeling  and  simulation  provide  the  “simulation  study”  (Banks, 
Carson,  Nelson,  &  Nicol,  2010)  as  an  accepted  approach  in  building  models  and 
simulations.  Different  versions  of  the  simulation  study  exist,  and  can  contain  from  10-12 
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steps,  but  the  focus  of  this  research  is  on  the  first  three  steps  (identifying  the  problem, 
setting  the  objectives,  and  conceptual  modeling)  using  the  version  proposed  by  Banks 
(Banks  &  Gibson,  2001).  Investigation  into  the  first  two  steps  of  the  simulation  study  and 
guidance  from  the  QKD  research  sponsor  lead  to  five  research  questions  that  provided 
insight  necessary  for  the  final  two  primary  research  questions. 

Two  issues  in  building  any  simulation  are  validation  and  verification.  The  first  is 
a  question  of  “did  we  model  the  right  thing?”  and  the  seconds  is  “did  we  build  the  right 
model?”  The  QKD  simulation  needs  to  answer  these  questions  or  risk  non-acceptance 
from  the  end-users  and  project  sponsors.  To  that  end,  this  research  proposes  to  use 
conceptual  model  validity  theory  and  the  DEVS  modeling  formalism  to  increase  the 
validity  of  the  simulation,  and  is  the  focus  of  the  journal  article  in  chapter  7. 

1.4. 1  Research  Focus  &  Methodology 

Creating  a  conceptual  model  is  the  third  step  of  the  simulation  study  and  the 
primary  focus  of  this  research.  This  conceptual  model  is  the  bridge  to  link  the 
mathematical  models  provided  by  the  Subject  Matter  Experts  (SMEs)  to  the  computer 
code  created  by  the  project  coders  for  the  selected  simulation  framework.  Conceptual 
modeling  increased  the  validity  of  the  simulation  by  using  several  well-accepted 
validation  and  verification  (V&V)  techniques  and  expressing  the  conceptual  model  using 
a  well-documented,  proven,  modeling  formalism. 

The  intent  of  this  research  is  to  explore  these  primary  and  secondary  research  objectives: 

Primary  objectives: 
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1 .  Develop  conceptual  models  for  each  optical  component  identified  for  the 
prototypical  QKD  architecture 

2.  Use  conceptual  model  validity  theory  to  increase  the  validity  of  the  simulation 

Secondary  research  objectives: 

1.  Enumerate  the  elements  contained  in  QKD  systems. 

2.  Identify  the  requirements  for  a  robust  QKD  modeling,  simulation,  and  analysis 
capability. 

3.  Propose  a  simulation  environment  which  meets  the  needs  of  the  research. 

4.  Develop  a  prototypical  QKD  system  architecture  for  analysis  in  the  dissertation 
research. 

This  research  focused  on  the  proper  modeling  of  the  temporal  behavior  and 
internal  “state”  of  optical  components  for  creating  conceptual  models  for  use  in  the  qkdX 
simulation.  This  researcher,  in  consultation  with  SMEs  in  the  optical  physics  and 
electrical  engineering  domains,  determined  the  necessary  detail  level  for  each  model. 
These  models  enable  a  system-level  simulation  where  signals  propagate  through  the 
system  as  discrete  events,  but  can  be  reconstructed  into  a  continuous-time  representation 
when  requiring  mathematical  operations  or  transformations  of  the  signals. 

To  capture  the  temporal  behavior  and  the  state  of  components,  this  researcher 
used  DEVS.  In  the  past,  DEVS  has  been  used  to  model  high-level  architectures,  hybrid- 
systems,  cell-spaces,  distributed  supply  chains,  test  &  evaluation,  forest  fires, 
environmental  systems,  building  performance  models,  and  other  problem  spaces  (Gunay, 
O'Brien,  Goldstein,  Breslav,  &  Khan,  2013;  Mittal,  Risco,  &  Zeigler,  2007;  Ntaimo, 
Zeigler,  Vasconcelos,  &  Khargharia,  2004;  G.  A.  Wainer  &  Giambiasi,  2001;  G.  Wainer, 
2006;  B.  P.  Zeigler,  Kim,  &  Buckley,  1999;  B.  P.  Zeigler,  Song,  Kim,  &  Praehofer,  1995; 
B.  P.  Zeigler,  Ball,  Cho,  Eee,  &  Sarjoughian,  1999).  This  research  represents,  to  the 
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team’s  knowledge,  the  first  use  of  DEVS  to  model  optical  components. 

1.5  Document  Organization 

This  document  uses  a  journal  format  to  present  work  related  to  conceptual 
modeling  of  optical  components  using  DEVS.  Chapter  2  presents  my  research  questions 
and  discusses  how  the  research  questions  link  to  four  of  the  included  articles. 
Additionally,  it  presents  the  methodology  for  testing  the  DEVS  atomic  and  coupled 
models. 

Chapter  3  is  the  article  “Quantum  Key  Distribution:  A  Revolutionary  Security 
Technology”  published  in  the  ISSA  Journal,  a  trade  publication  of  the  Information 
Systems  Security  Association  (Grimaila  et  ah,  2012).  This  article  presents  a  “layman’s” 
explanation  of  QKD  technology  and  the  BB84  protocol.  It  is  included  only  as  background 
information  for  better  understanding  QKD. 

Chapter  4  presents  the  article  “Towards  Modeling  and  Simulation  of  Quantum 
Key  Distribution  Systems.”  This  article  appeared  in  the  International  Journal  of  Emerging 
Technology  and  Advanced  Engineering  (Morris  et  ah,  2014).  It  presents  the  research 
findings  for  several  of  the  secondary  research  questions. 

Chapter  5  is  the  article  titled  “A  Survey  of  Quantum  Key  Distribution  (QKD) 
Technologies.”  The  book  Emerging  Trends  in  ICT  Security  (Morris,  Grimaila,  Hodson, 
Jacques,  &  Baumgartner,  2013)  contains  this  article  as  its  chapter  9.  This  material 
highlights  research  into  QKD  technologies  to  identify  optical  components  for  the 
prototypical  QKD  architecture. 

Chapter  6  contains  the  article  titled  “A  Reference  Architecture  to  Enable  Security 
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and  Performance  Analysis  of  Quantum  Key  Distribution.”  This  article  presents  a 
discussion  of  the  baseline  reference  QKD  architecture  used  in  the  conceptual  modeling 
research.  It  reviews  some  of  the  design  decisions  made  for  d  the  reference  architecture 
and  is  under  review  at  IEEE  Transactions  on  Emerging  Topics  in  Computing. 

Chapter  7  is  the  article  titled  “Using  the  Discrete  Event  System  Specification  to 
Model  Quantum  Key  Distribution  System  Components.”  This  article  is  the  capstone  of 
the  research  using  the  DEVS  framework.  It  includes  a  discussion  on  how  the  conceptual 
were  built,  the  modeling  process  and  how  the  research  modeling  efforts  increased  the 
validity  of  the  qkdX  simulation  and  is  under  review  at  the  Journal  of  Defence  Modeling 
and  Simulation. 

Chapter  8  documents  the  results  and  analysis  of  the  conceptual  modeling  effort.  It 
describes  the  modeling  steps  and  lists  the  component  and  coupled  submodules  built 
during  the  research.  It  discusses  testing  the  models  and  provides  examples  of  model  code 
and  output  data. 

Chapter  9  presents  the  conclusions,  significance  of  this  work,  and 
recommendations  for  further  research.  Chapter  10  contains  the  references  for  chapters  1- 
2,  and  8-10.  Each  embedded  article  and  the  27  appendices  have  its  own  reference  list, 
focused  on  the  material  in  that  document. 

Appendix  A  contain  systems  engineering  material  relating  to  the  QKD 
prototypical  architecture,  a  decomposition  of  the  QKD  system  down  to  the  individual 
optical  components  within  the  Alice  quantum  module  and  offers  descriptions  of  the 
software  tools  used  in  this  research.  Appendix  B  contains  information  on  the  component 
creation  and  the  testing  methodology  and  has  examples  of  testing  output  for  both 
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components  and  coupled  submodules.  Appendix  C  is  a  short  primer  on  cryptography,  the 


next  seventeen  contain  the  DEVS  research  documentation  for  each  modeled  optical 
component  and  the  final  seven  appendices  cover  the  modeled  coupled  submodules  for  the 
“Alice”  portion  of  a  QKD  system.  See  Table  1  for  a  concise  list. 


Table  1.  List  of  Appendices. 


Appendix 

# 

Title 

Contents 

A 

QKD  Prototypical 
Architecture 

System  Engineering  &  decomposition  diagrams 

B 

Component 

Creation  and 

Testing 

Overview  of  creating  &  testing  steps 

C 

Cryptography 

Overview 

Primer  on  cryptography 

D 

Bandpass  Eilter 

Component  description,  DEVS  documentation  &  Use 
Cases 

E 

Beamsplitter 

Component  description,  DEVS  documentation  &  Use 
Cases 

E 

Circulator 

Component  description,  DEVS  documentation  &  Use 
Cases 

G 

Optical 

Photodiode 

(Classical 

Detector) 

Component  description,  DEVS  documentation  &  Use 
Cases 

H 

EVOA 

Component  description,  DEVS  documentation  &  Use 
Cases 

I 

Eixed  Attenuator 

Component  description,  DEVS  documentation  &  Use 
Cases 

J 

Half-wave  Plate 

Component  description,  DEVS  documentation  &  Use 
Cases 

K 

In-line  Polarizer 

Component  description,  DEVS  documentation  &  Use 
Cases 

E 

Isolator 

Component  description,  DEVS  documentation  &  Use 
Cases 

M 

Easer 

Component  description,  DEVS  documentation  &  Use 
Cases 

N 

PM  Eiber 

Component  description,  DEVS  documentation  &  Use 
Cases 

9 


0 

Polarization 

Controller 

Component  description,  DEVS  documentation  &  Use 
Cases 

p 

Pulse  Modulator 

Component  description,  DEVS  documentation  &  Use 
Cases 

Q 

Polarizing 

Beamsplitter 

Component  description,  DEVS  documentation  &  Use 
Cases 

R 

SM  Fiber 

Component  description,  DEVS  documentation  &  Use 
Cases 

S 

Optical  Switch 

Component  description,  DEVS  documentation  &  Use 
Cases 

T 

WDM 

Component  description,  DEVS  documentation  &  Use 
Cases 

U 

CPG  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

V 

PM  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

w 

DSG  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

X 

CTQ  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

Y 

OSL  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

Z 

TPG  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

AA 

0PM  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 
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2.  Methodology 


The  purpose  of  this  chapter  is  to  present  the  research  questions,  their  place  within 
the  overall  research  and  the  methodology  used  for  the  research.  Each  question  has  a  short 
discussion  and  highlights  the  chapter  containing  the  article  focused  on  that  research. 

2.1  Research  Questions 

A  search  of  simulation  literature  provided  an  accepted  path  for  creating  a 
simulation:  the  simulation  study.  In  simulation  literature,  the  accepted  practice  to 
approach  problem  solving  is  to  use  a  methodical  simulation  study  (Banks,  1998;  Elliott, 
Edmondson,  Scrudder,  Igarza,  &  Smith,  2009;  Geoffrion,  1989;  Gogg  &  Mott,  1998; 
Jain,  1991;  Naylor  &  Einger,  1967). 

Simulation  studies  have  many  suggested  steps,  and  Banks  suggests  a  version  of 
the  simulation  study  supported  in  literature  and  drawn  from  research  started  in  the  1960s 
(Banks  &  Gibson,  1997;  Banks,  1998;  Banks  &  Gibson,  2001;  Banks  &  Chwif,  2010; 
Banks  et  ah,  2010;  Eaw,  Kelton,  &  Kelton,  1991;  R.  E.  Shannon,  1998).  Banks  writes 
extensively  on  this  topic  and  the  DOD  MSCO  references  the  process  as  a  best  practice 
(Morse  et  ah,  2010).  Banks’  simulation  study  includes  many  steps  but  the  scope  of  this 
research  is  his  first  three  steps: 

•  Problem  formulation 

•  Setting  of  objectives  and  overall  project  plan 

•  Model  conceptualization 

This  research  addressed  these  steps  by  posing  multiple  research  questions.  The 
questions  explore  the  topics  necessary  to  address  the  simulation  study  steps  and  meet  the 
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requests  of  the  project  sponsor.  The  intent  was  to  conduct  research  to  answer  the 
questions,  meet  the  needs  of  the  project  sponsor  and  support  the  research  objectives  of 
the  AFIT  QKD  research  team. 

Five  initial  questions  were  posed  after  conducting  a  literature  review  and 
discussions  with  SMEs  and  project  sponsor.  Answering  these  questions  laid  the 
foundation  for  the  research  into  the  conceptual  model  for  the  QKD  simulation.  The  five 
questions  were: 

2.1.1  Ql:  What  Are  the  Basic  Elements  of  a  QKD  System? 

This  research  focused  on  identifying  the  elements  of  QKD  (components, 
architectures,  phases  and  processes)  and  distilling  a  list  of  optical  components  selected 
for  inclusion  in  the  prototypical  demonstration  architecture.  These  components  were  the 
focus  of  the  DEVS  modeling  research.  The  primer  article  in  chapter  3  provides  the  basic 
understanding  of  QKD  and  the  article  in  chapter  4  presents  an  overview  of  QKD 
technologies  found  during  this  research. 

2.1.2  Q2:  What  End  User  Capabilities  are  required  in  a  QKD  Modeling  and 

Simulation  Framework? 

Evaluating  the  needs  of  users  served  a  dual  purpose:  1)  provided  research  into  a 
topic  requested  by  the  project  sponsor  to  ensure  the  QKD  simulation  provided 
capabilities  relevant  to  the  eventual  end-users,  2)  captured  requirements  for  inclusion  in 
the  conceptual  model  and  demonstration  architecture.  Chapter  5  contains  the  article 
discussing  the  research  for  this  question. 
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2.1.3  Q3:  What  Software  Developer  Capabilities  are  required  in  a  QKD 
Modeling  and  Simulation  Framework? 

The  project  sponsor  also  requested  researching  developer  capabilities  for  the 
QKD  simulation.  These  results  lead  to  identifying  additional  requirements  for  inclusion 
in  the  conceptual  models  and  the  demonstration  architecture.  Chapter  5  contains  the 
article  discussing  the  research  for  this  question. 

2.1.4  Q4:  Which  Simulation  Environment  Is  Best  for  QKD  Modeling  and 
Simulation? 

This  research  was  exploration  and  comparison  of  various  simulation  software 
packages  to  select  the  best  simulation  environment  for  building  the  QKD  simulation. 
Both  open-source  and  professional  software  packages  were  considered,  leading  to 
identifying  the  best  solution,  based  on  the  capabilities  identified  in  the  earlier  research 
questions  and  input  from  the  project  sponsor.  Chapter  5  contains  the  article  discussing  the 
research  for  this  question. 

2.1.5  Q5:  What  QKD  System  Architecture  is  Best  Suited  to  Demonstrate  the 
Analysis  Capabilities  of  the  Proposed  Framework? 

This  question  addressed  creating  a  QKD  system  architecture  using  the  optical 
components  identified  by  the  first  research  question.  A  demonstration  QKD  simulation 
built  by  the  AFIT  research  team  modeled  this  architecture  using  the  simulation 
environment  identified  in  the  previous  question  as  a  proof-of-concept  project.  Chapter  6 
has  the  draft  article  discussing  the  qkdX  simulator  and  the  prototypical  architecture.  This 
article  is  still  in  the  draft  stage,  with  submission  to  the  IEEE  Transactions  on  Emerging 
Topics  in  Computing  expected  by  mid- August. 
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2.1.6  Q6:  What  is  the  DEVS  formalism  for  each  component  within  the 

prototypical  QKD  system? 

The  purpose  of  this  question  is  to  use  the  DEVS  formalism  to  describe  the 
conceptual  models  for  the  selected  prototypical  QKD  system  per  the  3  step  of  the 
simulation  study.  The  DEVS  formalism  provides  a  comprehensive  description  of  the 
system  in  an  accepted  modeling  and  simulation  formalism.  The  DEVS  formalism  aids  the 
model  developers,  provides  increased  validation  of  the  QKD  simulation,  and  supports 
testing  and  evaluation.  Chapter  7  is  the  article  submitted  to  The  Journal  of  Defense 
Modeling  and  Simulation  for  review  and  provides  a  discussion  on  the  DEVS  formalism 
for  an  example  coupled  submodule  and  an  example  optical  component. 


2.1.7  Q7:  How  can  we  use  the  DEVS  formalism  and  conceptual  model  validity 
theory  to  increase  the  validity  of  the  QKD  simulation? 

The  purpose  of  this  question  is  to  mate  the  DEVS  formalism  to  conceptual  model 
theory  to  increase  the  perceived  validity  and  confidence  in  the  QKD  simulation 
conceptual  models  by  using  theory,  techniques,  and  principles  of  V&V.  This  was 
accomplished  by  applying  several  V&V  techniques  and  providing  the  following  list  of 
products: 

•  English-language  rules  for  each  component  and  module 

•  Phase  Transition  Diagrams  for  each  component  and  module 

•  Event-Trace  Diagrams  for  each  component  and  module 

•  SME  math-based  behavioral  models  for  each  component  (SME  input) 

•  DEVS  pseudo  code  for  each  component  and  module 

The  research  for  each  component  starts  with  a  description  of  the  component 
derived  from  commercial  data  sheets  and  academic  texts  describing  the  components.  This 
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provided  the  necessary  information  to  build  a  conceptual  model  for  the  component.  Phase 
transition  diagrams  showed  timing  and  behavior  and  event-trace  diagrams,  in  the  form  of 
state  list  tables,  described  the  transitions  between  states  for  several  test  cases.  This 
information,  with  the  SME-provided  mathematical  behavior  models,  became  the  basis  for 
constructing  the  DEVS  pseudocode. 

DEVS  provides  a  way  to  formalize  the  conceptual  model  of  the  QKD  simulator, 
but  in  itself  does  not  provide  conceptual  model  validity.  While  verification  and  validation 
are  normally  used  together,  validation  is  the  focus  of  this  research.  Model  validity  is  a 
necessary  condition  for  the  credibility  of  simulation  results  (Balci,  1995).  Model 
validation,  according  to  Balci,  is  “substantiating  that  the  simulation  model,  within  its 
domain  of  applicability,  behaves  with  satisfactory  accuracy  consistent  with  the  study 
objectives”  (Balci,  1997).  Model  validation  is  the  comparison  of  model  behavior  to  the 
behavior  of  the  system  under  study  when  both  are  responding  to  identical  input 
conditions  (Sargent,  2005).  The  article  in  chapter  7  (pages  7-8)  discusses  conceptual 
modeling,  DEVS,  and  how  using  DEVS  increases  the  validity  of  a  simulation. 

2.2  Methodology 

The  methodology  for  creating  the  DEVS  models  for  each  component  and  coupled 
submodule  is  the  same  and  the  results  for  each  are  included  in  the  appendices.  Chapter  7 
explains  the  methodology  in  detail  and  explains  the  research  results.  The  basic  procedure 
started  with  the  optical  physics  SME  creating  a  mathematical  model  for  each  of  the 
optical  components  that  captured  parameters  and  behavior  believed  necessary  for  the 
model.  Model  creation  used  a  combination  of  data  measured  during  laboratory 
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experiments  and  component  data  sheets  and  existing  reference  literature.  Creating  and 
verifying  the  correctness  of  the  developed  math  models  used  Mathematica,  a  well-known 
math  computation  software  package  (Wolfram,  2014). 

The  next  step  was  to  transform  the  mathematical  model  into  a  DEVS  pseudocode 
model.  These  mathematical  models  become  the  “source  system”  shown  in  Figure  1  and 
consequently,  the  basis  for  QKD  simulator.  The  modeler  reviewed  the  math  models  to 
understand  the  necessary  transformation  functions,  reviewed  quantum  and  optical  physics 
literature  and  consulted  with  the  SMEs  to  understand  the  required  component  behavior. 
Product  literature  for  existing  physical  components  provided  additional  information  for 
acceptable  component  input  and  output  ranges.  The  DEVS  models  captured  this 
information  using  phases,  states  and  transitions  and  submitted  the  component  models 
back  to  the  optical  SME  for  review. 

Once  complete,  the  DEVS  pseudocode  became  the  basis  for  creating  the  model  in 
a  DEVS -compliant  simulator,  MS4ME  (MS4  Systems,  2014).  MS4ME  is  a  product  of 
RTSync  (www.rtsync.com),  a  spin-off  from  the  Arizona  Center  of  Integrative  Modeling 
and  Simulation  (ACIMS)  (Arizona  State  University,  2014).  MS4ME  provides  a 
structured  user  interface  for  modeling  built  on  top  of  the  DEVSJAVA  simulator  (B.  P. 
Zeigler,  Sarjoughian,  &  Au,  1997).  For  each  component,  the  output  from  the  MS4ME 
simulator  was  compared  against  the  expected  behavior  of  the  DEVS  model.  This 
modeling  was  a  check  on  the  DEVS  pseudocode  and  ensured  the  models  met  the 
requirements  of  the  formalism  and  captured  the  appropriate  behavior.  Once  checked,  the 
DEVS  pseudocode  became  the  basis  for  the  simulation  modelers  to  create  the  qkdX 
framework. 
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Conceptual 

Modeling 

DEVS  research 


Figure  1.  Levels  of  modeling  and  simulation. 

2.2.1  Component  testing 

The  components  were  tested  within  the  MS4ME  simulator,  with  the  results  shared 
with  the  SME  for  face  validity  and  trace  checking  (see  chapter  6  for  explanation  of  these 
validation  techniques),  as  well  as  using  operational  graphics  (viewing  the  model  as  it 
moves  through  time)  and  fixed  values  (using  constants  for  model  input  and  internal 
variables  to  check  against  calculated  values).  These  four  techniques  are  a  subset  of  the 
suggested  validation  techniques  by  Sargent  for  validation  of  simulation  models  (Sargent, 
2005). 


Appendix  B  describes  the  component  creation  and  testing  process,  with  a  section 
on  component  behavior  testing,  a  section  with  an  example  of  the  MS4ME  output  from  a 
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test  case  used  for  the  EVOA,  and  section  listing  a  “pseudocode”  derived  from  code 
comments  within  the  EVOA  code. 

The  steps  of  the  creating  and  testing  process  were: 

•  Component  description  -  describing  the  component  function  and  physical  design 
using  commercial  and  academic  literature. 

•  Component  conceptual  model  -  text  description  of  the  properties  and  behaviors  of 
interest  in  the  component. 

•  English-language  rules  -  list  of  rules  that  describe  the  behavior  of  the  component. 

•  Phase  transition  diagram  -  diagram  that  shows  how  the  component  moves  from 
phase  to  phase  within  each  state.  This  diagram  is  described  in  detail  in  chapter  6. 

•  Event-trace  diagram  -  diagrams  and  tables  describing  how  the  component  moves 
from  phase  to  phase  for  several  test  cases. 

•  Use  case  -  list  of  use  cases  for  the  component. 

•  DEVS  code  -  DEVS  pseudocode  for  the  component;  used  to  create  the  MS4ME 
models. 

•  MS4ME  code  -  programming  the  pseudocode  into  the  MS4ME  simulator  as  a 
check  to  ensure  the  pseudocode  captured  the  behavior  and  timing  properly. 

•  MS4ME  output  review  -  a  line-by-line  check  of  the  MS4ME  output  to  ensure  the 
MS4ME  model  and  the  pseudocode  matched  and  the  MS4ME  programming  was 
correct. 

•  MS4ME  model  review  -  the  optical  SME  reviewed  the  DEVS  conceptual  model 
along  with  the  MS4ME  models  to  ensure  the  modeled  behavior  and  timing  was 
correct  in  comparison  to  the  starting  mathematical  model. 

•  Model  refactor  -  after  review,  each  model  was  corrected  per  feedback  from  the 
optical  SME. 

This  is  just  a  short  overview  of  the  process,  see  appendix  B  for  a  detailed  description. 

2.2.2  Methodology  Issues 

A  major  component  of  validating  the  DEVS  pseudocode  was  using  the  MS4ME 
DEVS  simulator,  but  several  issues  arose  during  its  use.  MS4ME  is  still  in  development 
and  the  researcher  discovered  issues  that  affected  the  research.  The  most  important  of 
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these  was  the  lack  of  advanced  math  functions  in  the  DEVS-JAVA  language  that  is  the 
basis  of  MS4ME. 

The  design  of  optical  packets  uses  integration  functions  to  determine  several 
values  during  simulation  execution.  This  design  required  integrating  a  scientific  library 
into  the  qkdX  simulation  framework,  but  the  researcher  found  the  MS4ME  simulator 
failed  when  trying  to  install  a  comparative  JAVA-language  scientific  library.  This  issue 
was  reported  to  RTSync,  but  there  was  no  fix  to  this  issue  during  the  research  period. 

This  problem  affected  research  during  the  coupled  submodules  building  phase. 
Each  time  an  optical  packet  reflects,  there  should  be  an  optical  power  reduction 
calculated  using  the  integration  functions.  The  missing  integration  functions  led  to  optical 
packets  reflecting  infinitely  between  components.  Each  component  was  tested 
individually  for  proper  behavior  by  injecting  low-power  packets  and  ensuring  the  fiber 
components  properly  deleted  these  low-power  packets  per  the  simulation  design  choice  to 
have  the  fiber  modules  delete  packets  below  a  specified  power  level. 

The  generally  accepted  method  ensuring  validity  of  a  simulation  is  to  compare  the 
simulation  output  to  a  real-world  system.  The  closer  the  outputs  (or  the  harder  it  is  to 
distinguish  between  the  two),  the  stronger  the  validity.  This  method  is  not  applicable 
when  simulating  future  or  notional  systems,  and  in  this  research,  not  having  access  to  real 
systems  for  comparison.  Additionally,  the  prototypical  architecture  was  intentionally 
created  not  to  model  any  existing  QKD  system  but  rather  to  exercise  the  capabilities  of 
qkdX. 

To  overcome  these  deficiencies,  the  researcher  relied  on  guidance  from  an  optical 
physics  SME  who  provided  the  mathematical  models  for  the  optical  components.  The 
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SME  reviewed  each  DEVS  and  MS4ME  model  for  accuracy  (as  noted  in  the  previous 
discussion  on  research  methodology)  to  ensure  they  captured  the  proper  behavior.  Eate 
into  this  research  period,  the  AEIT  QKD  research  team  did  receive  a  QKD  system,  but 
there  was  no  time  to  capture  data  from  this  system. 

2.2.3  Included  Articles 

The  following  five  chapters  contain  articles  focused  on  the  various  aspects  of  this 
research.  Chapter  3  contains  the  first  article  which  provides  a  layman’s  primer  on  QKD. 
Chapter  4  presents  an  overview  of  QKD  technologies  and  networks,  part  of  the  research 
into  identifying  the  components  necessary  to  model  QKD  systems.  Chapter  5  focuses  on 
identifying  requirements  and  capabilities  for  modeling  QKD  and  selection  of  a  simulation 
environment.  Chapter  6  presents  the  qkdX  simulation  built  by  the  AEIT  research  team  and 
discusses  the  components  and  submodules  necessary  to  model  the  demonstration  QKD 
architecture.  Einally,  chapter  7  presents  the  research  into  DEVS,  writing  the  DEVS 
pseudocode  and  how  using  DEVS  can  increase  the  validity  of  QKD  simulation. 


20 


3.  Quantum  Key  Distribution:  A  Revolutionary  Security  Technology 


Grimaila,  M.  R.,  Morris,  J.  D.,  &  Hodson,  D.  (2012).  Quantum  Key  Distribution:  A 
Revolutionary  Security  Technology.  The  ISSA  Journal,  27,  20-21 . 

Published  in:  ISSA  Journal,  Volume  27,  June  2012 

12  Pages 


Note:  This  article  has  been  changed  from  its  published  format  for  inclusion  in  this 
document. 
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Quantum  Key  Distribution:  A  Revolutionary  Security 

Technology 

Michael  R.  Grimaila,  Jeffrey  Morris,  and  Douglas  Hodson 
Air  Force  Institute  of  Technology,  Wright-Patterson  AFB,  OH  45433-7765 

Introduction 

Quantum  Key  Distribution  (QKD)  is  a  revolutionary  security  technology  that  exploits  the 
laws  of  quantum  mechanics  to  achieve  information-theoretic  secure  key  exchange.  QKD 
enables  two  parties  to  “grow”  a  shared  secret  key  without  placing  any  limits  on  an 
adversary’s  computational  power.  QKD  is  unique  in  its  ability  to  detect  the  presence  of 
any  third-party  eavesdropping  on  the  key  exchange.  Due  to  the  fundamental  laws  of 
quantum  mechanics,  any  third-party  eavesdropping  on  the  key  exchange  will  introduce 
detectable  errors.  If  the  errors  are  below  a  defined  threshold,  an  unconditionally  secure 
key  can  be  distilled.  When  QKD  is  used  in  conjunction  with  the  On-Time  Pad  symmetric 
cryptographic  algorithm,  the  result  is  an  unconditionally  secure  cryptographic  system.  In 
this  article,  we  provide  a  brief  background  of  cryptography  related  to  QKD,  present  the 
basic  principles  the  BB84  QKD  protocol,  and  discuss  vulnerabilities  arising  from  the 
non-idealities  present  in  real  world  QKD  system  implementations. 

Secure  Communications  and  Cryptography 

The  need  for  secure  communications  has  existed  since  the  dawn  of  humanity. 
Cryptography,  the  practice  and  study  of  techniques  for  securing  communications  between 
two  authorized  parties  in  the  presence  of  one  or  more  unauthorized  third  parties,  is  an 
essential  tool  used  to  assure  information  security  (Rivest,  1990).  Historically,  government 
and  military  applications  chiefly  used  cryptography,  but  today  almost  everyone  is 
dependent  on  cryptography  as  it  is  used  to  provide  security  services  including 
confidentiality,  integrity,  authentication,  authorization,  and  non-repudiation  (NIST  800- 
21,  1995). 

A  cryptosystem  is  composed  of  two  basic  components:  an  algorithm  and  one  or  more 
keys.  The  algorithm  is  the  mathematical  transformation  used  to  encrypt  and  decrypt 
messages  and  the  key(s)  are  parameters  used  in  the  encryption  and  decryption  processes. 
Figure  1  shows  a  block  diagram  of  a  simple  cryptosystem.  The  original  message,  m, 
called  the  “plaintext”  transforms  into  the  “ciphertext”,  EK(m),  using  the  encryption 
algorithm,  E,  and  the  encryption  key,  K.  The  terms  plaintext  and  ciphertext  refer  to 
binary  data  and  can  represent  anything  in  digital  form  (e.g.,  text,  audio,  video,  pictures, 
programs).  Other  parameters  (e.g.,  initialization  vectors,  salt,  etc.)  may  be  used  but  are 
not  shown  for  simplicity.  Ideally,  the  ciphertext  is  not  decipherable  unless  you  possess 
the  key  required  to  decrypt  it'.  The  transformation  of  plaintext  into  ciphertext  “protects” 


*  This  is  not  strictly  true  as  the  strength  of  most  cryptographic  algorithms  is  rooted  in  the  effort  required  to 
solve  difficult  mathematical  problems.  The  science  of  cryptanalysis  is  focused  upon  learning  the  secret  key 
based  upon  analysis  of  the  ciphertext,  as  well  as  other  information  related  to  the  encryption  and  decryption 
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the  confidentiality  of  messages  transmitted  over  a  public  channel  where  an  adversary  can 
possibly  intercept  it.  Upon  receipt,  the  ciphertext  message  is  transformed  back  into  the 
plaintext,  m,  using  the  decryption  algorithm,  D,  and  the  decryption  key  K'.  The 
decryption  algorithm,  D,  is  the  inverse  transformation  of  the  encryption  algorithm,  M, 
which  means  that  Dk'  {E}^(m))=m.  Note  that  in  general  K  does  not  have  to  equal  K', 
although  it  does  for  symmetric  algorithms. 


m  — I 
plaintext 


encryption  key 


E,(m) 

ciphertext 


eavesdropping 

adversary 


Ok'  (EK(m))  =  m 
plaintext 


decryption  key 


Figure  1  -  A  Simple  Cryptosystem  Block  Diagram 


There  are  three  basics  types  of  cryptographic  algorithms:  symmetric,  asymmetric  and 
hashing  functions.  Symmetric  key  algorithms  use  the  same  key  (e.g.,  K  =  K')  for 
encryption  and  decryption.  The  benefits  of  a  symmetric  key  algorithm  are  that  it  provides 
confidentiality,  is  fast,  is  easily  implemented  in  hardware,  and  consumes  little 
computational  power  when  compared  to  asymmetric  algorithms.  However,  symmetric 
key  algorithms  only  provide  confidentiality  and  require  a  separate  key  for  each  pair  of 
entities  who  wish  secure  communications,  which  does  not  scale  well  when  large  numbers 
of  entities  must  securely  communicate.  Examples  of  symmetric  key  algorithms  include 
DES,  3-DES,  AES,  Blowfish,  RC4,  and  RC5. 


Asymmetric  key  algorithms  used  mathematically  related,  but  different  (e.g.,  K  K'),  key 
pairs  for  encryption  and  decryption  (e.g.,  public  and  private  keys)  which  reduces  the  key 
distribution  burden.  The  benefits  of  an  asymmetric  key  algorithm  are  that  there  no  need 
for  “out  of  band”  key  distribution  as  public  keys  are  freely  shared,  it  scales  better  since 
only  a  single  key  pair  needed  for  each  individual,  and  additionally  provides 
authentication  and  non-repudiation.  However,  asymmetric  key  algorithms  are  slow 
because  they  require  complex  mathematical  operations  and  typically  consume  more 
computational  power  than  symmetric  algorithms.  Examples  of  asymmetric  algorithms 
include  RSA,  PGP,  El  Gamal,  EGG,  and  Diffie-Hellman. 


Hash  algorithms  are  one-way  functions  that  take  an  arbitrary  length  message  and  create  a 
fixed  length  message  digest.  Hash  algorithms  may  or  may  not  require  a  key  depending  on 
their  mode  of  operation.  Hashing  provides  an  efficient  way  to  check  the  integrity  of 
stored  or  transmitted  data  without  having  to  compare  the  data  bit  by  bit.  However,  since 
hash  algorithms  map  all  possible  inputs  to  a  fixed  length  message  digest,  more  than  one 


process.  As  technology  progresses,  an  adversary  with  unlimited  computational  resources  may  be  able  to 
decode  the  ciphertext  in  a  “reasonable”  amount  of  time.  There  are  concerns  that  certain  cryptographic 
algorithms  will  become  useless  when  quantum  computers  with  a  larger  number  of  qbits  become  viable. 
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input  can  map  to  the  same  digest  creating  a  “collision”  which  may  provide  an  advantage 
to  an  eavesdropper.  Examples  of  hash  algorithms  include  MD-4,  MD-5,  and  SHA-1. 

Different  cryptographic  algorithms  can  be  used  independently  or  can  be  combined  in  a 
hybrid  fashion  to  provide  robust  security  services.  For  example,  a  web  browser  that 
interacts  with  a  secure  web  server  using  SSL/TLS  uses  all  three  of  the  primary 
cryptographic  algorithms. 

The  One-Time  Pad  (OTP) 

The  only  cryptographic  algorithm  mathematically  proven  to  be  unconditionally  secure  is 
the  One-Time  Pad  (OTP).  The  OTP  is  a  symmetric  cryptographic  algorithm  and  is 
relatively  easy  to  understand.  The  first  known  description  of  the  OTP  was  in  1882  when 
Frank  Miller  described  “superencipherment”  as  a  means  to  insure  the  privacy  and  secrecy 
of  telegraphic  communications  (Bellovin,  2011).  Miller’s  method  required  the  use  of  a 
randomly  generated  key  that  was  never  reused.  In  1917,  Gilbert  Vernam  invented  and 
later  patented  a  cipher  based  on  teleprinter  technology,  but  it  was  vulnerable  because  it 
reused  key  material  (Vernam,  1919;  Vernam,  1926).  Despite  this  weakness,  a  National 
Security  Agency  report  identified  Vemam’s  patent  as  “perhaps  one  of  the  most  important 
in  the  history  of  cryptography”  (Kahn,  1996).  Subsequently,  Joseph  Mauborgne 
recognized  that  if  the  key  used  in  the  Vernam  cipher  was  fully  random,  then  cryptanalysis 
would  be  impossible.  In  the  1940s,  Claude  Shannon  proved  the  theoretical  significance 
of  the  security  of  the  OTP  (Shannon,  1949). 

The  strength  of  all  other  modern  cryptographic  algorithms  is  based  upon  “computational 
security,”  which  means  that  it  is  considered  secure  if  there  is  a  negligible  probability  of 
determining  the  key  in  a  “reasonable”  amount  of  time  using  current  technology.  In 
theory,  every  cryptographic  algorithm,  except  the  OTP,  is  insecure  given  enough 
ciphertext,  computational  resources,  and  time^. 

To  use  the  OTP,  each  of  the  parties  (common  called  Alice  and  Bob)  who  wish  secure 
communications  must  first  share  a  key  "pad"  which  is  a  randomly  generated  key,  equal  in 
length  to  the  message  to  be  sent^.  Alice  transforms  the  plaintext  into  the  ciphertext  by 
bitwise  Exclusive- ORing  (XORing)  the  plaintext  with  the  key  pad.  The  XOR  operation 
of  two  bits  is  calculated  as  follows:  if  the  bits  are  the  same  you  will  obtain  a  0,  and  if  the 
bits  are  different  you  will  obtain  a  1.  Once  Alice  has  encrypted  the  plaintext  into  the 
ciphertext,  she  destroys  the  key  pad  and  transmits  the  ciphertext  message.  Upon  receiving 
the  message.  Bob  XORs  the  ciphertext  message  with  the  same  key  pad  used  by  Alice  to 
recover  the  plaintext  message  and  then  destroys  his  key  pad. 


^  Recent  developments  in  quantum  computing  have  placed  the  security  of  certain  cryptographic  algorithms 
(e.g.,  RSA)  which  are  based  upon  the  difficulty  of  factoring  large  numbers  into  their  constituent  primes  at 
risk. 

^  This  simple  requirement  is  the  most  limiting  factor  when  using  the  OTP  as  you  must  have  a  virtually 
infinite  supply  of  a  shared  secret  key  available  to  Alice  and  Bob. 
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For  example,  suppose  Alice  wants  to  securely  send  a  message  (10  01)  to  Bob  using  the 
OTP  as  shown  in  Figure  2.  First,  Alice  and  Bob  must  preshare  a  secret  key  pad  (0101) 
that  is  the  same  length  as  the  message.  Next,  Alice  XORs  the  plaintext  message  (10  01) 
with  the  key  (0101)  to  obtain  the  ciphertext  (110  0).  Alice  now  sends  the  ciphertext 
through  the  public  insecure  network.  When  Bob  receives  the  ciphertext  (110  0),  he 
XORs  it  with  the  key  pad  (0101)  to  recover  the  plaintext  (10  01).  One  way  to  think 
about  the  OTP  is  that  the  key  pad  is  “noise”  that  mixes  with  the  plaintext  to  create  the 
ciphertext.  Since  only  Alice  and  Bob  have  the  same  noise  source  (key  pad),  they  are  the 
only  ones  who  can  filter  it  out. 


Alice  -  Sender  Bob  -  Receiver 


Figure  2  -  The  One-Time  Pad 


For  the  OTP  to  be  secure,  the  key  pad  must  be  1)  truly  random,  and  2)  never  reused.  Not 
meeting  either  of  these  conditions  significantly  reduces  the  strength  of  the  security  of  the 
OTP.  This  lesson  was  learned  by  the  Soviet  Union  who  during  WWII  reused  one-time 
pads  after  distributing  them  to  Soviet  intelligence  field  agents  (Benson,  2006).  As  a 
result,  US  and  UK  intelligence  agencies  working  on  Project  VERONA  were  able  to 
easily  decode  their  messages  (USGPO,  1997). 

To  take  advantage  of  the  OTP,  we  must  generate  and  distribute  random^  secret  keys  to 
both  Alice  and  Bob  equal  in  length  to  the  sum  of  the  lengths  of  all  messages  to  be 


^  The  generated  key  must  be  truly  random.  This  is  not  a  trivial  requirement  but  due  to  space  constraints  we 
will  not  expand  on  this  point. 
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exchanged.  In  practice,  this  places  a  significant  burden  on  key  distribution  and 
management  as  one  must  continuously  generate  and  distribute  key  pads  between  the 
authorized  entities  in  a  secure  manner.  For  this  reason,  historically  the  OTP  is  only  used 
in  environments  which  justify  the  costs  involved  with  secure  key  distribution.  However, 
QKD  offers  an  attractive  point-to-point  solution  to  this  dilemma. 

Quantum  Key  Distribution  (QKD) 

The  beginning  of  QKD  can  be  traced  back  to  Stephen  Wiesner  who  developed  the  idea  of 
quantum  conjugate  coding  in  the  late  1960’s  (Wiesner,  1983).  As  a  student  at  Columbia 
University,  he  described  two  applications  for  quantum  coding:  a  method  for  the  creation 
of  fraud-proof  banking  notes  (quantum  money)  and  a  method  for  the  transmission  of 
multiple  messages  in  such  a  way  that  reading  one  of  the  messages  destroys  the  others 
(quantum  multiplexing).  Wiesners’s  quantum  multiplexing  utilizes  photons  polarized  in 
conjugate  bases  as  quantum  bits  (qbits)  in  order  to  pass  information.  In  this  manner,  if  the 
receiver  measures  the  photons  in  the  correct  polarization  basis,  they  will  receive  a  correct 
result  with  high  probability.  However,  if  the  receiver  measures  the  photons  in  the 
incorrect  (conjugate)  basis,  they  will  obtain  a  random  result  and  destroy  all  information 
about  the  original  basis.  In  1984,  Charles  Bennett  and  Gilles  Brassard  exploited  this 
concept  when  they  proposed  the  first  QKD  protocol,  BB84,  for  secure  communication 
(Bennett  and  Brassard,  1984). 

The  BB84  Protocol 

In  the  BB84  protocol,  the  qubits  are  single  photons  polarized  into  one  of  four  polarization 
states  selected  from  one  of  two  conjugate  basis  sets  as  shown  in  Figure  3.  The  Rectilinear 
Basis  is  shown  in  yellow  and  is  comprised  of  0°  and  90°  polarizations,  and  the  Diagonal 
Basis  is  shown  in  blue  and  is  composed  of  45°  and  135°  polarizations. 


Vertical 
90°  Polarization 
Bit  =  1 


/Anti-Oiagonal 
135°  Polarization 
Bit  =  1 


Diagonal 
45°  Polarization 
Bit  =  0 


Horizontal 
0°  Polarization 
Bit  =  0 


X 


Rectilinear 

Basis 


Diagonal 

Basis 


Figure  3  -  The  Rectilinear  and  Diagonal  Bases  Sets 
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Alice  randomly  generates  both  a  bit  (0  or  1)  and  a  basis  (Rectilinear  or  Diagonal), 
polarizes  a  photon  accordingly,  and  sends  it  to  Bob.  Bob  randomly  selects  a  basis 
(Rectilinear  or  Diagonal)  to  measure  the  arriving  polarized  photon.  If  Bob’s  randomly 
selected  basis  matches  Alice’s  basis.  Bob  will  measure  the  bit  encoded  by  Alice  with 
100%  accuracy^.  If  Bob’s  basis  does  not  match  Alice’s  basis,  he  will  measure  the  correct 
bit  with  50%  probability  because  a  photon  polarized  in  one  basis  yields  a  random  value 
when  measured  in  its  conjugate  basis.  By  encoding  classical  bits  in  two  conjugate  bases, 
the  BB84  protocol  provides  a  means  for  passing  keys  between  two  parties  in  such  a  way 
that  an  eavesdropper  would  destroy  information  and  be  detected. 

The  BB84  protocol  consists  of  a  sender,  Alice,  and  a  receiver.  Bob,  connected  by  a 
classical  public  channel  and  a  quantum  channel  as  shown  in  Figure  4.  The  classical 
channel  is  a  conventional  authenticated  public  communications  link  and  is  used  to 
conduct  error  reconciliation  during  the  key  exchange  process.  It  is  assumed  that  only 
passive  eavesdropping  may  take  place  on  the  classical  channel  as  long  as  some  initial  key 
material  is  shared  for  authentication.  The  quantum  channel  is  used  to  exchange  the 
quantum  encoded  qubits.  BB84  is  often  called  a  “Prepare  and  Measure”  QKD  protocol 
because  Alice  prepares  the  photons  and  Bob  measures  them.  The  BB84  protocol  can  be 
broken  into  four  steps:  Quantum  Exchange,  Sifting,  Information  Reconciliation,  and 
Privacy  Amplification. 
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Public  Channel 
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^Admin^ 
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Figure  4  -  A  BB84  QKD  System  Block  Diagram 


Quantum  Exchange 

The  first  step  in  the  BB84  protocol  is  for  Alice  to  generate  a  random  bit  string  which  is 
the  initial  candidate  key  string.  She  also  generates  a  random  bit  string  which  is  used  to 
select  the  basis  (Rectilinear  or  Diagonal)  used  to  encode  the  bits  as  polarized  photons. 
Alice  transmits  one  polarized  photon  to  Bob  for  each  bit  of  the  key  string  using  the 


^  In  reality,  errors  can  be  induced  by  the  environmental  noise,  equipment  non-idealities,  or  a  malicious 
adversary  snooping  on  the  quantum  channel. 
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associated  random  basis.  Bob  receives  these  qubits  and  randomly  chooses  a  basis  in 
which  to  measure  them.  If  Bob  chooses  correctly,  he  will  receive  the  same  bit  value  that 
Alice  transmitted  (assuming  perfect  transmission  and  no  interference).  If  he  chooses 
incorrectly,  then  Bob  has  a  50%  probability  of  obtaining  the  correct  value. 

Sifting 

After  Bob  receives  all  of  the  qubits  measured  in  randomly  generated  bases,  he 
communicates  his  choice  of  basis  for  each  qubit  to  Alice.  Alice  responds  to  Bob 
identifying  those  bit  positions  for  which  Bob’s  basis  agreed  with  her  basis.  Alice  and  Bob 
both  discard  any  bits  for  which  their  measurement  basis  differed.  At  this  point,  Alice  and 
Bob  should  have  an  identical  set  of  bits  which  are  a  subset  of  the  original  candidate  key 
string  transmitted  by  Alice. 

Information  Reconciliation 

Information  reconciliation  is  a  very  important  step  in  the  BB84  protocol  as  this  is  where 
the  error  rate  is  calculated  and  will  reveal  the  presence  of  an  eavesdropper.  Errors  can 
result  from  many  sources  including  non-idealities  in  equipment,  environmental  noise, 
and/or  an  eavesdropper  which  causes  a  mismatch  between  Alice’s  and  Bob’s  sifted  key. 
In  order  to  meet  the  guaranteed  security  requirement,  it  is  assumed  that  all  errors  are  due 
to  eavesdropping. 

Alice  and  Bob  first  conduct  error  estimation  by  systematically  sampling  a  random  subset 
of  bits  from  the  sifted  key  and  compare  them  over  the  open  channel.  If  all  the  bits  agree, 
then  it  is  likely  that  they  have  the  same  version  of  the  key  which  can  be  verified  with  a 
hash.  The  bits  exposed  during  the  public  comparison  are  discarded  from  the  final  key 
before  the  hash  is  applied.  If  there  are  errors  present  in  the  sifted  key,  information 
reconciliation  is  used  to  identify  and  correct  disagreement  between  Alice’s  and  Bob’s 
sifted  key.  Error  reconciliation  requires  the  exchange  of  information  over  the  classical 
public  channel  and  as  a  consequence  it  “leaks”  some  information  about  the  sifted  key. 
Eor  this  reason,  the  method  used  for  information  reconciliation  is  a  critical  design  choice. 
Common  information  reconciliation  protocols  include  Cascade,  Winnow,  and  Eow 
Density  Parity  Codes  (EDPC). 

Privacy  Amplification 

During  the  information  reconciliation  process,  an  eavesdropper  can  gain  partial 
information  about  the  sifted  key  by  eavesdropping  both  on  the  quantum  channel  (where 
they  introduce  detectable  errors)  and  on  the  public  channel.  Privacy  Amplification  is  used 
to  reduce,  and  effectively  eliminate,  an  eavesdropper's  knowledge  of  the  sifted  key  to  an 
arbitrary  small  value.  This  can  be  achieved  by  using  a  universal  hash  function  chosen  at 
random  from  a  publicly  known  set  of  such  functions.  The  inputs  to  the  function  are  the 
sifted  key  and  the  error  rate  calculated  during  the  information  reconciliation  process.  A 
final  key  is  produced  that  is  shortened  based  on  how  much  information  an  eavesdropper 
could  have  gained  about  the  original  sifted  key. 
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A  simplified  example  of  the  BB84  protocol  is  shown  in  Figure  5.  The  figure  shows  the 
quantum  exchange,  sifting,  and  error  estimation  steps.  The  information  reconciliation  and 
privacy  amplification  processes  are  not  shown  for  simplicity. 
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Figure  5.  BB84  Protocol  Example  (R=Rectilinear,  D=Diagonal) 

If  an  eavesdropper  present,  even  with  infinite  computational  power,  the  best  they  could 
do  in  an  ideal  system  would  be  to  intercept  transmissions  from  Alice,  randomly  select  a 
basis  for  measurement,  and  retransmit  those  qubits  in  the  basis  that  they  selected.  Since 
an  eavesdropper  does  not  know  the  basis  Alice  transmitted  in,  they  would  be  correct,  on 
average,  only  50%  of  the  time.  When  they  retransmit  the  qubits  to  Bob  he  will  also  select 
a  random  basis  for  measurement,  and  will  be  correct,  on  average,  50%  of  the  time.  The 
combination  of  these  steps  will  introduce  a  25%  error  into  the  sifted  key.  Therefore,  if 
Alice  and  Bob  detect  an  error  rate  of  25%  or  higher  in  their  sifted  key,  they  conclude  that 
there  is  an  eavesdropper  present  and  abandon  the  key  exchange  process.  This  is  the  basis 
for  the  unconditional  security  that  the  BB84  QKD  protocol  achieves  because  Alice  and 
Bob  can  always  detect  the  presence  of  an  eavesdropper. 

Real  World  QKD  Limitations 

If  it  sounds  too  good  to  be  true,  then  it  probably  is.  The  ideal  BB84  protocol  assumptions 
include:  1)  Alice  emits  perfect  single  photons;  2)  the  channel  between  Alice  and  Bob  is 
noisy  but  lossless;  3)  Bob  has  single  photon  detectors  with  perfect  efficiency;  and  4)  the 
basis  alignment  between  Alice  and  Bob  is  perfect.  If  these  conditions  are  met,  QKD 
provides  for  an  “unconditionally  secure”  key  exchange,  as  shown  in  several  mathematical 
proofs  (Mayers,  2001;  Renner,  Gisin,  &  Kraus,  2005;  Shor  &  Preskill,  2000).  However, 
many  of  these  assumptions  are  not  valid  when  building  real  world  systems.  For  example, 
the  protocol  relies  on  the  transmission  of  single  photons  because  if  there  are  multiple 
photons  sent  an  adversary  may  be  able  to  intercept  and  measure  a  photon  while  letting  the 
remaining  photons  pass  unaffected.  Reliable  on-demand  photon  generation  is  not 
currently  practical,  so  instead  a  weak  coherent  photon  pulse  is  generated  and  attenuated 
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so  that  on  average  there  are  only  0.1  photons  in  each  packet  (that  means  only  1  in  10 
packets  will  contain  a  photon).  This  significantly  reduces  the  efficiency  of  the  protocol, 
but  is  required  to  limit  and  bound  the  knowledge  gained  by  an  eavesdropper.  At  the 
receiving  side,  single  photons  must  be  reliably  detected.  Unfortunately,  single  photon 
detectors  are  rate  limited,  have  low  detection  efficiencies,  and  spuriously  trigger.  Even 
when  there  is  no  eavesdropper  present,  the  physical  characteristics  of  the  quantum 
channel  can  introduce  errors  which  affect  the  polarization  of  the  photons  while  in  transit. 
The  result  of  these  technical  limitations  is  that  the  final  key  rate  is  reduced  and  errors  are 
introduced  into  the  sifted  key  even  though  there  is  no  malicious  eavesdropper  present. 
These  errors  must  be  corrected  before  using  a  cryptographic  algorithm  since  Alice  and 
Bob  must  have  identical  copies  of  the  key. 

QKD  Vulnerabilities 

After  the  release  of  the  BB84  protocol  and  the  realization  that  an  “unconditionally 
secure”  key  exchange  could  exist,  several  researchers  published  papers  on  various  ways 
to  attack  the  protocol,  creating  the  new  field  of  “quantum  hacking”  (Liitkenhaus,  2000; 
Myers,  Wu,  &  Pearson,  2004;  Scarani,  Acin,  Ribordy,  &  Gisin,  2004).  Even  the  creators 
of  the  BB84  protocol  mused  on  ways  to  gain  information  about  the  shared  key  and  how 
to  mitigate  the  leaked  information  (Bennett,  Brassard,  Crepeau,  &  Maurer,  1995).  Others 
have  proposed  new  protocols  that  minimize  the  problems  with  the  BB84  protocol,  but 
introduce  other  problems  or  require  hardware  devices  with  the  same  limitations  as  the 
BB84  protocol  (Barrett,  Hardy,  &  Kent,  2005;  BruB,  1998;  Cerf,  Bourennane,  Karlsson, 
&  Gisin,  2002;  Grosshans  &  Grangier,  2002). 

Conclusions 

QKD  provides  significant  advantages  when  compared  to  conventional  key  distribution. 
Eirst,  the  security  of  QKD  security  rests  on  the  foundations  of  quantum  mechanics.  This 
is  in  stark  contrast  to  traditional  key  distribution  protocols  which  rely  on  computational 
security  where  the  computational  difficulty  of  certain  mathematical  functions  is  the 
foundation  of  security.  Second,  when  using  QKD,  one  can  determine  if  an  adversary  is 
eavesdropping  on  the  link  because  it  will  induce  errors  in  the  key  exchange  process.  In 
contrast,  traditional  key  exchange  algorithms  cannot  provide  any  indication  of 
eavesdropping  or  guarantee  of  key  security. 

As  with  any  new  technology,  there  is  a  gap  between  the  theory  and  the  implementation  of 
the  BB84  protocol  in  the  real  world.  Over  the  last  28  years,  research  in  the  QKD  area  has 
matured  the  technology  and  resulted  in  commercial  QKD  implementations.  With  the 
current  generation  of  hardware,  QKD  systems  can  only  reliably  generate  share  keys  over 
distances  of  approximately  100km  using  terrestrial  optical  fiber  systems.  As  the  distance 
increases,  the  generated  key  rate  drops.  At  long  distances,  QKD  systems  cannot  generate 
enough  key  material  to  support  bulk  encryption  using  the  OTP.  However,  commercial 
QKD  systems  such  as  the  id  Quantique  Cerberis^  system  combine  a  conventional  high¬ 
speed  layer  2  encryption  engine  with  the  unconditional  security  of  QKD  technology.  In 


®  http://www.idquantique.com/network-encrvption/cerberis-laver2-encrvption-and-qkd.html 
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this  case,  the  key  generated  by  the  QKD  system  is  used  as  the  symmetric  key  for  an 
Advanced  Encryption  Standard  (AES)  bulk  encryptor.  In  this  mode  of  operation,  the  AES 
key  can  be  changed  based  upon  the  key  generation  rate  of  the  QKD  system.  Eor  example, 
the  AES  key  could  be  changed  once  per  minute  if  the  QKD  system  is  able  to  generate  at 
least  128  key  bits  per  minute. 

Einally,  interest  in  QKD  research  continues  to  grow  each  year.  The  race  is  on  to  improve 
the  quality  of  emitters,  detectors,  and  fiber  to  enable  QKD  to  operate  over  greater 
distances  and  at  higher  key  rates.  It  is  only  a  matter  of  time  before  you  will  encounter  a 
QKD  system  in  your  security  infrastructure. 

Disclaimer 

The  views  expressed  in  this  paper  are  those  of  the  authors  and  do  not  reflect  the  official 
policy  or  position  of  the  United  States  Air  Eorce,  the  Department  of  Defense,  or  the  U.S. 
Government. 
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INFDRMATIDN  IN  THIS  CHAPTER 

•  Defining  Quantum  Key  Distribution 

•  Reviewing  Quantum  Key  Distribution  architectures 

•  Exploring  Quantum  Key  Distribution  networks 

•  Identifying  the  key  technologies  for  future  Quantum  Key  Distribution  research 

•  Viewing  a  Quantum  Key  Distribution  usage  scenario 


Cryptography 

Cryptography,  the  practice  and  study  of  techniques  for  securing  communications  between  two 
authorized  parties  in  the  presence  of  one  or  more  unauthorized  third  parties,  is  the  centerpiece  of  a 
centuries-old  battle  between  code  maker  and  code  breaker  [1].  Historically,  government  and  mili¬ 
tary  applications  chiefly  used  cryptography,  but  today  almost  everyone  is  dependent  on  cryptogra¬ 
phy  to  provide  security  services  including  confidentiality,  integrity,  authentication,  authorization, 
and  non-repudiation  [2]. 

The  strength  of  commonly  used  cryptographic  algorithms  relies  on  computational  security, 
which  means  the  algorithm  is  secure  if  there  is  a  negligible  chance  of  discovering  the  key  in  a  “rea¬ 
sonable”  amount  of  time  using  current  computational  technology  [3].  As  computational  technology 
progresses,  adversaries  may  be  able  to  acquire  enough  computational  power  to  decode  encrypted 
messages  in  a  “reasonable”  amount  of  time.  In  fact,  recent  developments  in  quantum  computing 
technology  (including  supporting  algorithms)  have  placed  certain  classes  of  commonly  used  asym¬ 
metric  cryptographic  algorithms  (e.g.,  those  that  rely  on  the  difficulty  of  factoring  large  numbers 
into  their  constituent  primes,  such  as  the  Rivest,  Shamir,  and  Adleman  (RSA)  algorithm),  at  risk 
[4,1].  The  resulting  loss  of  security  in  commonly  used  asymmetric  public  key  cryptographic  algo¬ 
rithms  will  likely  increase  the  usage  of  symmetric  cryptographic  systems  and  intensify  the  need  for 
secure  and  efficient  key  distribution. 
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Quantum  key  distribution 

The  genesis  of  Quantum  Key  Distribution  (QKD)  can  be  traced  back  to  Stephen  Wiesner,  who 
developed  the  idea  of  quantum  conjugate  coding  in  the  late  1960s  [5].  As  a  student  at  Columbia 
University,  he  described  two  applications  for  quantum  coding:  a  method  for  creating  fraud-proof 
banking  notes  (quantum  money)  and  a  method  for  broadcasting  multiple  messages  in  such  a  way 
that  reading  one  of  the  messages  destroys  the  others  (quantum  multiplexing).  Wiesner’ s  quantum 
multiplexing  uses  photons  polarized  in  conjugate  bases  as  “qubits”  to  pass  information.  In  this  man¬ 
ner,  if  the  receiver  measures  the  photons  in  the  correct  polarization  basis,  he  or  she  receives  a  cor¬ 
rect  result  with  high  likelihood.  However,  if  the  receiver  measures  the  photons  in  the  wrong 
(conjugate)  basis,  the  measured  result  is  random,  and  due  to  the  measurement,  all  information  about 
the  original  basis  is  destroyed. 

In  1984,  Charles  Bennett  and  Gilles  Brassard  proposed  the  first  QKD  protocol,  BB84,  for 
secure  key  exchange  based  on  Wiesner’ s  ideas  [6].  The  goal  of  the  system  is  to  provide  perfect 
secrecy  during  key  distribution.  Using  the  BB84  protocol,  a  sender  and  receiver  “grow”  an 
unconditionally  secure  secret  key  by  leveraging  properties  of  quantum  mechanics  in  the  form  of 
polarized  photons  that  are  transmitted  from  the  sender  to  the  receiver.  Because  of  the  quantum 
properties  of  photons,  any  operations  performed  on  photons  in  transit  would  irrevocably  alter 
their  state,  which  would  be  detectable  by  the  receiver.  Additionally,  as  stated  by  the  no-cloning 
theorem,  no  photon  copies  can  be  produced  for  the  purpose  of  operating  on  the  copies  without 
affecting  the  original  photons. 

As  in  any  communications  system,  errors  may  be  introduced  from  a  wide  variety  of  sources.  In 
the  security  analysis  of  QKD  systems,  all  errors  are  attributed  to  a  hypothetical  adversary  (Eve) 
who  is  attempting  to  eavesdrop  on  the  key  distribution  communications.  If  the  errors  are  below  a 
defined  threshold,  the  two  parties  involved  in  the  key  exchange  can  distill  an  unconditionally  secure 
key  even  in  the  presence  of  an  adversary.  Otherwise,  the  key  exchange  is  aborted.  When  a  QKD- 
generated  unconditionally  secure  key  is  combined  with  the  one-time  pad  (an  unconditionally  secure 
classical  symmetric  cryptographic  algorithm),  the  result  is  an  unconditionally  secure  cryptographic 
system. 

Since  the  BB84  protocol  was  first  proposed,  there  have  been  many  QKD-related  protocols  and 
architectural  and  technological  developments  that  make  implementing  a  QKD  system  more  practi¬ 
cal  and  commercially  viable.  In  2001,  ID  Quantique  SA  offered  and  sold  the  first  commercially 
available  QKD  system  [7].  Today,  QKD  systems  are  available  globally  from  sellers  in  Europe  (ID 
Quantique,  http://www.idquantique.com/;  SeQureNet,  http://www.sequrenet.com/),  Australia 
(Quintessence  Labs,  http://qlabsusa.com/).  North  America  (MagiQ,  http://www.magiqtech.com/ 
MagiQ/Home.html),  and  Asia  (Quantum  Communication  Technology  Co.,  Ltd.,  http://www. 
quantum-info.com ). 

QKD  is  suitable  for  use  in  any  key  distribution  application  that  has  high  security  require¬ 
ments.  Existing  documented  applications  include  financial  transactions  and  electoral  communica¬ 
tions  [8,9],  but  there  are  numerous  potential  applications  in  law  enforcement,  government,  and 
military  applications.  The  commercial  systems  typically  use  QKD  as  a  means  to  produce  shared 
secret  keys  for  use  in  bulk  symmetric  encryption  algorithms,  such  as  the  Advanced  Encryption 
Standard  (AES),  instead  of  using  the  unconditionally  secure  one-time  pad.  In  this  case,  the  QKD- 
generated  key  is  used  to  update  the  encryption  key  frequently  (e.g.,  once  a  minute)  greatly 
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reducing  the  required  QKD  key  generation  rate  which  is  inversely  related  to  the  distance  between 
the  QKD  systems.  While  it  is  not  unconditionally  secure,  users  in  the  commercial  domain  con¬ 
sider  this  an  improvement  when  compared  with  updating  the  key  less  frequently  (e.g.,  daily  or 
monthly). 


Quantum  key  distribution  systems 

In  this  section,  we  present  a  historical  survey  of  the  development  of  QKD  systems  and  their  archi¬ 
tectures.  We  also  present  research  that  is  focused  on  developing  QKD  networks  that  can  broaden 
the  application  domains  of  QKD. 


QKD  system  architectures 
The  first  QKD  system:  BB84 

The  first  QKD  system  was  a  research  platform  built  in  1989  by  Bennett  and  Brassard  to  produce  a 
physical  realization  of  their  QKD  theory  [10].  This  system,  built  at  IBM’s  Thomas  J.  Watson 
research  center,  was  the  first  system  to  deal  with  the  issues  posed  by  non-ideal  hardware  as 
opposed  to  the  perfect  hardware  envisioned  in  QKD  theory.  The  system  used  a  weak-coherent  light 
source  to  generate  light  that  was  focused  by  a  lens,  passed  through  filters,  and  then  polarization 
modulated  using  Pockels  cells.  At  the  receiver,  the  entering  light  first  passed  through  a  Pockels 
cell,  selecting  the  polarization  measurement  basis,  then  went  to  a  prism  to  split  the  light  into  two 
paths  leading  to  photomultiplier  tubes  that  counted  the  number  of  photons  in  each  of  the  two  polari¬ 
zation  states  belonging  to  the  selected  measurement  basis.  The  distance  between  the  transmitters 
and  receiver  was  an  air-gap  of  roughly  30  cm.  The  platform  used  the  BB84  protocol  for  key  gener¬ 
ation  and  showed  that  QKD  could  be  implemented  using  standard,  non-ideal  components  [10]. 

Los  alamos:  QKD  leaves  the  laboratory 

In  1996,  Richard  Hughes  of  Los  Alamos  Laboratories  led  a  team  that  built  a  QKD  system  using 
14  km  of  underground  optical  fibers  [11].  Hughes’  system  used  the  B92  protocol  [12]  instead  of 
BB84 — the  B92  protocol  requires  that  the  system  be  able  to  generate  two  quantum  states  ratber 
than  four.  At  the  transmitter  (Alice),  the  system  used  a  1300  nm  laser  source  and  an  attenuator  to 
produce  weak,  coherent  pulses.  These  pulses  were  then  directed  to  a  50:50  fiber  coupler  that 
formed  the  input  to  an  unbalanced  Macb-Zebnder  Interferometer  (MZI)  that  split  the  incoming  pho¬ 
ton  packet  into  two  photon  packets.  In  the  MZI,  the  photons  that  traveled  along  the  long  arm  of  the 
interferometer  were  phase  modulated  relative  to  the  photons  that  traveled  along  the  short  arm  of 
the  interferometer.  The  pulse-to-pulse  randomly  selected  relative  phase  encoding  provided  the  bit 
and  basis  value  used  for  key  exchange.  At  tbe  output  of  tbe  MZI,  tbe  two  time-separated  photon 
packets  were  injected  into  the  14  km  fiber  leading  to  the  receiver. 

At  the  receiver  (Bob),  the  two  incoming  photon  packets  entered  another  unbalanced  MZI  identi¬ 
cal  to  the  one  at  the  transmitter.  The  phase  modulator  in  the  long  arm  of  Bob’s  MZI  was  used  to 
select  tbe  measurement  basis.  At  the  output  of  the  MZI,  the  photon  packet  that  passed  through  both 
the  long  arm  of  Alice’s  MZI  and  the  short  arm  of  Bob’s  MZI  interfered  with  the  photon  packet  that 
passed  through  the  short  arm  of  Alice’s  MZI  and  the  long  arm  of  Bob’s  MZI.  The  results  of  this 


144  CHAPTER  9  A  Survey  of  Quantum  Key  Distribution  (QKD)  Technologies 


interference  were  measured  using  a  time-gated  single-photon  Avalanche  Photo  Diode  (APD) 
detector. 


Plug  and  play:  QKD  made  easier 

In  1996,  Muller  et  al.  created  a  hardware-protocol  system,  based  on  Faraday  mirrors,  between  the 
cities  of  Nyon  and  Geneva  [13].  This  system  is  notable  for  automatically  compensating  for  birefrin¬ 
gence  and  polarization-dependent  losses  in  the  transmission  fiber.  This  system  attached  easily  to 
existing  telecommunication  fibers  with  no  need  for  adjustment  of  the  QKD  systems,  leading  to  the 
name  “plug  and  play.”  This  system  has  heralded  the  beginning  of  QKD  transitioning  from  the 
domain  of  the  physics  laboratory  to  existing  infrastructure. 

The  key  to  overcoming  the  effects  of  birefringence  in  the  “plug  and  play”  architecture  is  the  use 
of  Faraday  mirrors.  In  this  architecture.  Bob  generates  two  classical  level  light  pulses  that  he  sends 
to  Alice.  Alice  reflects  the  two  pulses  using  a  Faraday  mirror  (which  rotates  the  polarization  of  the 
incoming  light  so  that  the  reflected  light  is  orthogonally  polarized  to  the  incoming  light),  phase 
modulates  one  of  the  two  pulses  relative  to  the  other,  and  attenuates  both  pulses  to  the  single¬ 
photon  level.  The  fact  that  the  single-photon  light  pulses  returning  to  Bob  have  a  polarization 
orthogonal  to  what  they  had  when  they  traveled  to  Alice  undoes  any  birefringence  effects  the 
pulses  experienced  when  traveling  to  Alice. 

Damien  Stucki  and  his  teams  used  variations  of  the  “plug  and  play”  architecture  to  connect 
Geneva  and  Lausanne  [14],  a  distance  of  67  km,  over  regular  telecom  fiber  using  the  BB84 
protocol. 


First  entanglement-based  system:  EPR  and  Bell’s  theorem 

In  2004,  a  team  from  the  University  of  Geneva  proposed  and  built  a  system  utilizing  Ekert’s  E91 
QKD  protocol  based  on  quantum  entanglement  and  Bell’s  theorem.  This  protocol  uses  Bohm’s  ver¬ 
sion  of  the  Einstein-Podolsky-Rosen  (EPR)  experiment  and  Bell’s  theorem  to  test  for  eavesdrop¬ 
ping  [15].  This  system  was  one  of  the  first  to  demonstrate  the  use  of  entanglement  in  QKD.  The 
team’s  goal  was  to  demonstrate  a  system  using  violations  of  Bell’s  inequalities  as  the  foundation 
for  secure  key  exchange. 

This  system  uses  time-bin  entangled  qubits  created  from  a  laser  pulse  sent  through  an  unbal¬ 
anced  Michelson  interferometer  (short  and  long  leg),  then  through  a  type  1  Eithium  Triborate 
(EBO)  nonlinear  crystal,  where  spontaneous  parametric  down  conversion  creates  a  pair  of  entangled 
photons.  The  photons  pass  through  the  transmission  channel  to  both  Alice  and  Bob,  who  perform 
projective  measurements  using  the  same  type  of  unbalanced  interferometer.  Here,  a  significant  dif¬ 
ference  from  other  QKD  systems  is  that  the  photon  source  is  not  at  either  Alice’s  or  Bob’s  location, 
but  at  a  third  location.  By  placing  the  emitter  between  Alice  and  Bob,  the  system  is  able  to 
exchange  keys  at  twice  the  distance  of  a  conventional  system  with  the  same  loss. 

By  placing  the  photons  in  separate  time-bins  with  two  different  phases  and  using  the  Clauser- 
Horne-Shimony-Holt  (CHSH)  Bell  inequality,  an  upper  bound  for  correlations  can  be  determined. 
By  scanning  the  phases,  one  of  the  CHSH  parameters  can  be  inferred  and  the  correlation  coeffi¬ 
cients  of  the  CHSH  inequality  determined.  These  coefficient  values  prove  a  violation  of  the  CHSH 
inequality.  Nicholas  Gisin  proved  in  2002  that  when  the  Bell  inequality  is  violated,  the  entangled 
photons  can  be  used  in  QKD  [16]. 
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Continuous  variable  QKD:  short-ranged  but  fast  and  secure 

The  first  Continuous  Variable  QKD  (CV-QKD)  system  debuted  in  the  European  SEcure 
communication  based  on  Quantum  Cryptography  (SECOQC)  network,  with  the  prototype  built 
expressly  for  the  project.  Timothy  Ralph  first  described  the  CV-QKD  protocol  in  1999,  with  several 
variations  proposed  by  Cerf,  Assche,  Lutkenhaus,  and  Grosshans.  These  protocols  use  squeezed 
Gaussian  states  of  light  that  have  classical  intensity  levels  to  carry  information,  rather  than  discrete 
single  photon  states  [17—20]. 

This  system  encodes  information  in  the  amplitude  and  phase  of  the  classical  light  level  beam 
and  produces  high  rates  of  key  generation  over  a  short  distance  (such  as  a  metropolitan  network), 
as  it  is  not  as  sensitive  to  individual  photon  loss  as  the  discrete-variable  protocols.  Originally,  it 
was  not  suitable  over  long  distances  because  the  higher  noise  ratios  in  longer  fibers  created  errors 
in  the  quadratures  of  pulses,  interfering  in  the  homodyne  detection,  but  improvements  in  post¬ 
processing  have  increased  the  transmission  range.  The  protocol  is  resistant  against  general  and  col¬ 
lective  eavesdropping  attacks,  and  has  a  security  proof  for  coherent  attacks  as  well.  These  security 
proofs  show  it  is  more  secure  than  some  other  types  of  QKD  systems  against  attacks  that  exploit 
the  non-ideal  hardware  flaws  of  QKD  systems  [21]. 


QKD  networks 

Photon  loss  between  the  transmitter  and  receiver  due  to  attenuation  in  the  optical  fiber  connect¬ 
ing  the  transmitter  with  the  receiver,  coupled  with  dark  counts  at  the  receiver’s  detectors,  dra¬ 
matically  limits  the  maximum  effective  range  of  QKD  compared  to  classical  optical 
telecommunications.  However,  even  with  these  range  limitations,  researchers  have  implemented 
small-scale  QKD  networks  to  demonstrate  its  potential.  The  next  section  describes  some  of 
these  networks. 

DARPA  network:  introducing  layers 

In  2002,  the  Defense  Advanced  Research  Projects  Agency  (DARPA)  built  a  QKD  system  to 
explore  networks  that  had  multiple  Alice  and  Bob  system  pairs  rather  than  a  single  system  [22]. 
The  system  integrated  QKD-based  key  generation,  traditional  Ethernet  encryption,  and  key  manage¬ 
ment  to  secure  a  virtual  private  network  (VPN)  that  was  compatible  with  existing  telecommunica¬ 
tion  infrastructure. 

This  system  is  notable  for  demonstrating  QKD  using  existing  security  technology  and  introduc¬ 
ing  the  idea  of  “trusted  relays.”  This  relay  system  extends  the  range  of  a  QKD  network  but  intro¬ 
duces  the  concerns  of  adequately  securing  the  relays. 

SECOQC  Network:  mixing  and  matching  with  nodes 

Prom  2004  to  2008,  the  SECOQC  project  operated  in  Europe  to  design  and  set  up  a  network  of 
QKD  systems  to  show  the  uses  of  QKD  [23].  The  network  consisted  of  a  collection  of  point- 
to-point  systems  including:  three  plug  and  play  systems  by  ID  Quantique  SA;  a  one-way  weak-pulse 
system  from  Toshiba  Research  in  the  UK;  a  Coherent  One-way  System  (COW)  by  GAP  Optique-ID 
Quantique  S A- Austrian  Institute  of  Technology  (AIT);  an  entangled  photon  system  from  the 
University  of  Vienna  and  the  AIT;  a  continuous  variables  (CV-QKD)  system  by  Centre  National  de 
la  Recherche  Scientifique  (CNRS),  THALES  Research  and  Technology  and  Universite  Libre  de 
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Bruxelles;  and  a  free-space  link  by  the  Ludwig  Maximillians  University.  The  average  link  length 
was  between  20  km  and  30  km,  and  the  longest  link  was  83  km. 

The  project  created  a  QKD  trusted-repeater  network,  much  like  a  connected  graph,  where  each 
vertex  is  a  QKD  node  and  the  edges  are  the  QKD  communication  channels.  Each  link  retransmits 
key  material  along  the  link,  so  the  key  hops  from  link  to  link.  Keys  move  forward  using  an  algo¬ 
rithm  secured  with  QKD  key  material  to  the  next  node,  and  the  process  is  repeated  until  the  key 
reaches  its  destination.  This  creates  a  “trusted  repeater”  system,  where  each  node  is  secured  to  pre¬ 
vent  tampering  and  attack.  The  network  stripped  each  QKD  system  of  its  key  distillation  functions 
and  set  each  one  to  access  only  the  quantum  channel.  This  reduced  redundancy  between  tbe  sys¬ 
tems  and  moved  the  key  management  to  upper  layers  of  the  network  [23].  This  architecture  extends 
the  DARPA  network  in  both  number  of  nodes  and  the  key  transmission  maximum  distance. 

SwissQuantum  network:  simplifying  QKD  integration 

The  SwissQuantum  network  connected  three  nodes,  two  in  the  center  of  Geneva  and  one  at  the 
European  Organization  for  Nuclear  Research  (CERN),  with  a  maximum  length  of  17.1  km,  using 
ID  Quantique  SA  idSlOO  commercial  servers,  and  ran  between  March,  2009  and  January,  2011. 
Tbe  servers  used  tbe  BB84  and  SARG04  protocols  to  generate  a  shared  secret  key  for  standard 
Ethernet  network  encryptors  across  a  10  Gbps  channel.  This  network  introduced  the  concept  of 
layers  to  QKD  networks  [24]. 

Adding  a  mediation  layer  between  the  QKD  layer  and  the  secure  layer  allows  integration  of 
QKD  devices  into  an  existing  telecommunication  network.  The  focus  of  the  research  was  on  inte¬ 
gration  of  QKD  and  the  simplification  of  the  plug  and  play  architecture.  This  network  extended  the 
ideas  of  SECOQC  by  making  it  easier  to  add  QKD  to  an  existing  network  without  specially  adapt¬ 
ing  the  QKD  systems. 

Tokyo  network:  a  high-speed  network 

Much  like  the  SECOQC  network,  a  consortium  of  schools,  industry,  and  government  organizations 
created  a  tmsted-node  QKD  network  in  Tokyo  in  2010  to  explore  the  use  of  many  different  types  of 
QKD  working  together  [25].  The  Tokyo  network  created  a  secure  environment  to  demonstrate  secure 
television  conferencing,  secure  mobile  phones,  and  stable  long-term  operation  at  high  speeds. 

Nine  organizations  from  the  EU  and  Japan  employed  multiple  links  to  demonstrate  QKD  technol¬ 
ogies  such  as  several  decoy-state  BB84  systems,  a  Differential  Phase-Shift  (DPS)  QKD  demonstrator, 
an  entanglement  system,  and  ID  Quantique’s  commercial  QKD  system  [25].  The  network  consisted 
of  six  links,  with  a  maximum  link  distance  of  90  km.  The  network  was  designed  as  a  three-layer 
architecture  using  tmsted  nodes:  a  QKD  node,  a  key  management  layer,  and  a  communication  layer. 
The  key  management  layer  is  notable  for  passing  secret  keys  between  nodes  that  do  not  have  a  quan¬ 
tum  channel  by  using  the  unconditionally  secure  one-time  pad  cryptographic  algorithm. 


The  future  of  QKD 

The  short-term  future  of  QKD  lies  in  creating  and  extending  quantum  networks.  Until  the  maxi¬ 
mum  fiber  range  of  QKD  hardware  increases  significantly,  long-range  QKD  communications 
depends  on  some  form  of  multi-node  networks.  These  types  of  networks,  while  increasing  the  range 
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and  usability  of  QKD,  increase  the  security  concerns  of  the  telecommunications  provider.  Using  a 
trusted  node  within  a  network  increases  the  security  overhead  and  increases  the  possibility  of  cor¬ 
ruption  or  hijacking  of  the  quantum  channel.  Two  promising  areas  of  research  may  help  to  over¬ 
come  these  types  of  security  issues. 


Quantum  repeaters 

A  workable  long-range  QKD  network  needs  a  method  of  passing  qubits  from  one  network  segment 
to  the  next  without  destroying  the  quantum  particle.  Recall,  an  observer  cannot  clone  the  state  of  a 
quantum  particle  (i.e.,  the  no-cloning  theorem)  with  perfect  fidelity.  The  process  of  trying  to  clone 
a  quantum  state  introduces  unavoidable  noise  in  the  output,  so  the  copied  states  generated  by  the 
cloning  process  are  not  identical  to  the  input  state.  Hence,  the  quantum  information  carriers  cannot 
be  copied  (amplified)  as  is  typical  in  classical  communication  systems. 

For  a  quantum  “repeater”  to  work,  the  device  would  need  some  way  of  storing  the  quantum 
state  of  incoming  quantum  particles  for  a  brief  time  so  they  can  be  forwarded  to  another  QKD  sys¬ 
tem.  Quantum  entanglement,  quantum  teleportation,  and  quantum  memory  are  potential  tools  for 
building  a  quantum  repeater.  Quantum  entanglement  and  teleportation  would  allow  a  device  to 
receive  a  quantum  particle  from  a  sender,  and  then  entangle  that  photon  with  another  photon  in  the 
device,  which  will  be  sent  to  a  receiver  [26].  This  idea  is  the  basis  of  the  Quantum  Repeaters  for 
Long  Distance  Fibre-Based  Quantum  Communication  program  (QuReP)  (http://quantumrepeaters. 
eu),  a  project  funded  by  Switzerland,  Sweden,  France,  and  Germany.  This  multiyear  project  started 
in  2010  and  is  scheduled  to  finish  in  2013. 


Quantum  memory 

Quantum  memory  is  a  technology  needed  in  order  to  build  a  practical  quantum  repeater.  Quantum 
memory  allows  a  quantum  state  to  be  stored  for  some  amount  of  time  before  it  is  read  and  used. 
Current  research  centers  on  leveraging  the  properties  of  rare-earth  doped  crystals  as  the  basis  for 
holding  and  emitting  the  quantum  state.  This  memory  stores  a  copy  of  the  input  state,  destroying 
the  input  state  during  the  process,  and  can  output  a  perfect  copy  of  the  stored  input  state  with  high 
efficiency  ( >90%).  During  the  output  process,  the  quantum  state  of  the  memory  is  changed,  losing 
the  information  about  the  state  it  emitted.  Additional  research  centers  on  increasing  the  emission 
efficiencies  and  increasing  the  number  of  simultaneous  stored  states  [27]. 

Continued  research  using  spin-wave  storage  in  the  rare-earth  doped  crystals  and  experiments  in 
matter-matter  entanglement  has  led  to  Pr:YSO  and  Eu:YSO  rare-earth  crystals  that  absorb  a  quan¬ 
tum  state  and  emit  that  state  with  high  certainty  over  a  multi-minute  time  frame  [28,29]. 
Improvements  in  high-speed  photon  detectors,  single  photon  or  pure-state  emitters,  and  the  inter¬ 
faces  between  disparate  technologies  may  allow  these  memory  crystals  to  realize  quantum  repeaters 
within  the  next  decade. 


Free-space  QKD:  satellites 

With  technology  advancing  terrestrial  QKD,  advances  in  free-space  QKD  are  being  made.  Bennett 
and  Brassard  originally  demonstrated  free-space  QKD  in  their  first  device,  but  only  over  a  gap  of 
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30  cm.  Various  experiments,  including  some  of  the  networks  discussed  earlier  in  this  article,  used  a 
free-space  component  and  pushed  the  boundaries  for  QKD.  Improvements  in  lasers,  optical  tracking 
and  emitting  systems,  and  computers  and  software  have  allowed  the  free-space  QKD  distance  to  far 
exceed  that  of  terrestrial  QKD  [30—34]. 

Free-space  QKD,  with  maximum  distances  over  140  km,  has  been  demonstrated  by  an  experi¬ 
ment  in  the  Canary  Islands  of  La  Palma  and  Tenerife  in  2007  [33].  This  experiment  showed  that 
QKD  could  communicate  through  an  atmosphere  path  length  much  longer  than  that  between  a 
ground  station  and  a  low  earth  orbit  satellite.  The  experiment  used  a  variation  of  the  original  BB84 
protocol  and  used  telescopes  for  tracking  and  receiving.  This  experiment  showed  that,  using  free- 
space  QKD,  a  link  from  ground  to  an  orbiting  satellite  could  establish  a  secret  key  between  any 
two  ground  stations,  easing  the  key  distribution  problem  and  potentially  secure  ground-to-satellite 
communications . 

Chinese  researchers  are  working  with  free-space  experiments  with  the  intention  of  creating  an 
Earth-to-satellite  QKD  link.  In  2010,  one  group  demonstrated  a  QKD  system  using  a  ground  station 
and  a  balloon-based  transmitter.  They  developed  the  optics  and  tracking  systems  necessary  to  deal 
with  high  relative  angular  motion,  random  motion  of  the  platforms,  and  atmospheric  turbulence  that 
would  be  found  in  a  ground-to-satellite  system  [35].  Furthering  this  research,  another  group  in  China 
recently  reported  reflecting  a  beam  of  photons  off  an  orbiting  German  satellite  that  is  covered  with 
retro-reflectors.  These  reflected  enough  of  the  single  photons  back  to  a  receiving  telescope  to  meet 
the  standards  of  a  QKD  channel  [36].  Nicolas  Gisin  wrote  in  2010  that  he  would  not  be  surprised  if 
Chinese  researchers  are  the  first  to  demonstrate  a  QKD  link  between  Earth  and  a  satellite  [26] . 


Device  independent  QKD  (DI-QKD) 

QKD  provides  a  way  of  increasing  communications  security,  but  it  relies  on  several  assumptions: 
(i)  Alice  and  Bob  use  truly  random  number  generators,  (ii)  Alice  and  Bob  prepare  and  measure  the 
quantum  states  exactly  as  required  by  the  QKD  protocol,  (iii)  Alice  and  Bob  can  accurately  bound 
the  information  that  an  eavesdropper  gains  about  the  key  by  all  methods,  and  (iv)  Alice  and  Bob 
use  a  privacy  amplification  algorithm  that  eliminates  all  of  the  eavesdropper  information  about  the 
final  key.  A  major  advance  in  combating  this  information  leakage  to  the  eavesdropper  is  a  rela¬ 
tively  new  protocol  known  as  Device-Independent  QKD  (DI-QKD).  This  QKD  protocol  makes  no 
assumptions  about  the  hardware  used  by  Alice,  Bob,  and  Eve  and  goes  so  far  as  to  assume  that 
Alice  and  Bob  may  have  no  knowledge  about  how  their  hardware  works.  The  only  requirements 
are  that  Alice  and  Bob  randomly  select  their  measurement  basis  and  Eve  cannot  influence  this  ran¬ 
dom  selection  or  know  its  results  until  after  she  can  no  longer  act  on  the  quantum  states,  and  that 
Eve  does  not  know  the  results  of  Alice’s  and  Bob’s  measurements  [37]. 

The  DI-QKD  protocol  uses  a  form  of  Artur  Ekert’s  1991  entanglement-based  protocol  proposed 
by  Acin,  Massar,  and  Pironio  and  uses  CHSH  inequalities  to  provide  security  [38].  It  handles  the 
problem  that  real-life  implementations  differ  from  the  ideal  design.  It  also  makes  testing  of  compo¬ 
nents  easier  and  covers  the  scenario  where  the  quantum  devices  are  not  trusted  [39].  The  protocol 
has  been  proven  secure  against  collective  attacks  as  long  as  there  is  no  leakage  of  classical  informa¬ 
tion  from  Alice  and  Bob  [37].  Several  protocols  and  experiments  have  been  suggested  to  take 
advantage  of  DI-QKD,  including  using  heralded  qubit  amplification,  extending  the  range  and  key 
rate  of  normal  QKD  [40],  and  one  that  is  valid  against  most  general  attacks  and  based  on  any 
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arbitrary  Bell  inequalities,  not  just  those  based  on  CHSH  inequalities  [41].  Unfortunately,  DI-QKD 
requires  high-efficiency  near-perfect  detectors  and  provides  relatively  low  key  rates  due  to  the  need 
for  the  near-perfect  detections. 


Measurement  device  independent  QKD  (MDI-QKD) 

Though  DI-QKD  provides  increased  security  for  non-ideal  devices,  there  is  still  a  major  flaw  in 
today’s  implementations:  that  of  the  “detector  loophole.”  The  “loophole”  is  that  not  all  entangled 
photons  are  detected,  there  is  always  loss  in  a  quantum  channel,  each  detector  has  finite  detection 
efficiency  and  is  potentially  susceptible  to  side-channel  attacks.  All  of  these  factors  disturb  the 
Bell’s  inequality  tests  and  affect  protocols  based  on  such  tests,  ultimately  limiting  the  key  rate  and 
reducing  security  [40]. 

A  method  has  been  proposed  to  eliminate  all  detector  side-channel  information,  thus  avoiding 
the  problems  with  the  “detector  loophole.”  Measurement  Device  Independent  QKD  (MDI-QKD) 
portends  to  double  the  transmission  distance  for  normal  QKD  with  comparable  key  rates.  MDI- 
QKD  works  by  assuming  that  Alice  and  Bob  have  near-perfect  state  preparation  of  their  photons 
and  can  send  them  to  an  untrusted  relay  called  Charlie,  who  performs  Bell  state  measurements  that 
project  the  incoming  photons  into  a  Bell  state  [42].  Note  that  Charlie  can  he  untrusted  or  even 
under  the  control  of  Eve. 

The  MDI-QKD  protocol  tolerates  high  losses  for  communication  of  up  to  200  km,  assuming 
Charlie  is  placed  in  the  middle.  Unlike  the  DI-QKD,  this  protocol  doesn’t  require  the  use  of  Bell’s 
inequalities  and  can  be  used  for  any  QKD  system,  as  long  as  Alice  and  Bob  have  near-perfect  state 
preparation  as  in  phase  or  polarization-based  systems  [43]. 


A  military  QKD  usage  scenario 

How  could  the  QKD  benefit  be  used  in  a  military  environment?  Imagine  a  crisis  affecting  the 
United  States  in  the  near  future.  The  president  enters  his  command  center,  receiving  information 
from  around  the  globe  carried  by  satellites  and  telecommunication  circuits.  As  decisions  flow  from 
the  center,  the  secret  instructions  are  carried  by  regular  telecommunications  circuits  to  the 
Pentagon  and  have  been  encrypted  by  QKD  devices  providing  key  material  to  fast  network  encryp¬ 
tion  devices.  These  devices  change  their  large-bit  keys  several  times  a  second,  making  it  virtually 
impossible  for  cyber  adversaries  to  decrypt  the  traffic. 

Once  at  the  Pentagon,  these  decisions  are  coordinated  with  contingency  plans,  then  orders  are 
generated  to  forces  around  the  globe.  Once  the  orders  and  plans  are  ready,  the  information  is  sent 
to  satellites  in  orbit,  again  using  QKD-secured  circuits.  Not  only  are  the  ground-to-space  links  hard 
to  intercept,  the  data  is  encrypted  using  the  same  large-bit  network  encryptors.  The  signals  are  then 
sent  from  space  to  ground  stations  using  the  same  type  of  encrypted  circuits.  On  the  ground,  adver¬ 
saries  may  listen  in  on  the  space-to-ground  communications,  but  with  the  encryption  key  changing 
so  fast,  it  is  impossible  to  decrypt  the  data.  As  the  distance  for  QKD  links  increases,  many  more 
communication  circuits  could  be  secured  by  such  systems.  The  unconditionally  secure  nature  of 
QKD-generated  key  material  makes  it  attractive  for  high  security  requirements  often  found  in  the 
military  domain. 
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CONCLUSION 

QKD  provides  significant  security  advantages  when  compared  with  conventional  key  distribution. 
First,  due  to  the  laws  of  quantum  mechanics,  an  eavesdropper  cannot  copy  the  quantum  bits  used  in 
the  key  exchange.  Second,  increases  in  computing  power  do  not  help  an  adversary,  as  a  QKD- 
generated  key  is  unconditionally  secure.  Third,  QKD  allows  the  sender  and  receiver  to  know  if 
there  is  an  eavesdropper  listening  in  on  the  key  exchange.  Fourth,  the  security  of  QKD  security 
rests  on  the  foundations  of  quantum  mechanics.  As  long  as  an  eavesdropper  has  not  discovered 
new  laws  of  physics,  the  security  premise  of  QKD  holds  true.  This  contrasts  with  traditional  key 
distribution  protocols,  which  rely  on  computational  security  to  secure  the  key  [44]. 

As  QKD  technology  matures,  the  architecture  of  systems  will  change.  Since  quantum  states  ran¬ 
domly  selected  from  any  two  or  more  non-orthogonal  quantum  bases  can  be  used  to  encode  informa¬ 
tion  for  a  QKD  system,  there  are  many  ways  to  implement  such  a  system.  Current  research  focuses  on 
new  types  of  QKD,  such  DI-QKD  and  MDI-QKD,  which  provide  methods  to  overcome  the  security 
limitations  of  existing  hardware.  As  interest  in  QKD  continues  to  grow  and  commercial  QKD  systems 
become  more  common,  so  will  the  research  efforts  focused  upon  improving  the  quality  of  emitters, 
detectors,  and  fiber  to  enable  QKD  to  perform  over  greater  distances  and  at  higher  key  rates. 
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Abstract —  Quantum  Key  Distribution  (QKD)  is  a  next- 
generation  security  technology  that  exploits  the  properties  of 
quantum  mechanics  to  enable  two  parties  to  generate  an 
unconditionally  secure  shared  secret  key.  QKD  is  novel 
because  its  security  is  based  upon  the  fundamental  laws  of 
quantum  mechanics  and  not  on  computational  complexity. 
QKD  systems  are  composed  of  multiple  interconnected 
electrical,  optical,  and  electro-optical  subsystems  and 
computer-based  controllers  and  can  be  viewed  as  a  complex 
system  (or  system  of  systems).  Currently,  there  is  no  single 
simulation  framework  that  supports  a  high  level  systems 
engineering  analysis  of  QKD  system  architectures.  In  this 
paper,  we  present  an  evaluation  process  that  considers  end 
user  and  software  developer  requirements  for  the 
identification  and  selection  of  a  software  framework  suitable 
for  modeling,  simulation,  and  analysis  of  QKD  systems. 

Keywords — Requirements  analysis,  simulation 

environment,  discrete-event  simulation,  quantum  key 
distribution,  systems  engineering. 

I.  Introduction 

Cryptography,  the  practice  and  study  of  techniques  for 
securing  communications  between  two  authorized  parties 
in  the  presence  of  one  or  more  unauthorized  third  parties,  is 
the  centerpiece  of  a  centuries  old  battle  between  code 
makers  and  code  breakers  [1].  The  strength  of  commonly 
used  modern  cryptographic  algorithms  relies  on 
“computational  security,”  which  means  the  algorithms  are 
considered  secure  if  there  is  a  negligible  probability  of 
discovering  the  key  in  a  “reasonable”  amount  of  time  using 
current  computational  technology  [2].  However,  recent 
developments  in  quantum  computing  technology  and 
algorithms  threaten  to  place  certain  classes  of  commonly 
used  classical  cryptographic  algorithms,  such  as  the  Rivest, 
Shamir  and  Adleman  (RSA)  algorithm,  at  risk  of  being 
compromised  [1,3]. 

In  1984,  Bennett  and  Brassard  proposed  the  first  QKD 
protocol,  BB84,  to  provide  perfect  secrecy  during  key 
distribution  [4].  Using  a  QKD  protocol,  a  sender  and 
receiver  create  an  unconditionally  secure  secret  key  by 
leveraging  the  properties  of  quantum  mechanics. 


QKD  enables  two  parties  to  securely  “grow”  a  shared 
secret  key  since  any  third-party  eavesdropping  on  the  key 
exchange  would  introduce  detectable  errors.  An 
unconditionally  secure  cryptosystem  can  be  built  by 
combining  a  QKD-generated  key  with  the  One  Time  Pad 
(OTP)  symmetric  key  algorithm. 

Just  as  in  the  early  days  of  computing,  each  QKD 
system,  whether  commercial  or  research,  is  a  unique 
implementation  based  on  the  theory  and  principles  of  QKD 
using  currently  available  components,  protocols,  and 
technology.  Since  there  are  no  widely  accepted  security  and 
performance  standards  for  evaluating  QKD  systems,  each 
system  designer  architects  their  system  based  on  their  own 
views  and  needs.  Because  of  this,  there  is  a  need  to  model 
QKD  implementations  to  estimate  system  level  attributes 
such  as  security,  performance,  and  other  technical 
attributes. 

A  fundamental  truth  about  QKD  technology  is  that, 
because  of  the  limitations  of  technology,  it  is  impossible  to 
build  the  ideal  system  described  in  theory.  For  this  reason, 
each  QKD  implementation  is  only  an  approximation  of  the 
ideal  apparatus  described  in  theory.  Therefore,  our 
research  effort  is  focused  on  the  development  of  a  QKD 
modeling  and  simulation  framework  that  will  allow  system 
implementation  non-idealities  to  be  included  in  the  system 
analysis  so  their  impact  on  overall  system  performance  and 
security  can  be  better  understood  [5]. 

The  need  to  evaluate  different  QKD  system 
implementations  coupled  with  the  cost  of  the  systems,  the 
cost  of  testing,  the  uniqueness  of  each  system 
implementation,  and  the  relative  scarcity  of  resources 
creates  a  problem;  How  does  one  design,  develop,  test,  and 
analyze  QKD  systems  in  a  resource-constrained 
environment,  where  it  is  impractical  and  cost  prohibitive  to 
design,  develop,  build,  and  acquire  the  systems? 

A  practical  alternative  to  testing  the  actual  hardware  is  to 
develop  a  simulation  capability  that  can  accurately  model  a 
wide  variety  of  existing  and  proposed  QKD 
implementations  and  generate  the  analysis  needed.  This 
includes  the  ability  to  model  the  many  different  protocols 
currently  used  in  the  implementation  of  QKD  systems,  and 
also  the  ability  to  model  proposed  protocols. 
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Such  a  simulation  capability  needs  to  address  many 
“concerns,”  including  the  effects  due  to  the  quantum 
properties  of  light,  optical  components,  single-photon 
detectors,  and  the  behaviour  of  complex,  interacting  QKD 
software  processes  present  within  a  QKD  system.  Such  a 
simulation  must  facilitate  experimentation  so  that  the 
studies  conducted  can  generate  reasonable  estimates  for 
system  effectiveness,  performance,  security,  and  cost  based 
on  their  architecture,  components,  and  processes. 

In  this  paper,  we  present  an  evaluation  methodology  for 
selecting  a  simulation  tool  suitable  for  the  development  of  a 
QKD  modeling,  simulation,  and  analysis  framework.  The 
evaluation  methodology  is  based  upon  best  practices  and 
incorporates  identified  end  user  and  software  developer 
requirements. 

11.  End  User  And  Developer  Requirements 

A  fundamental  requirement  for  any  simulation  is  the 
ability  to  tailor  the  fidelity  (i.e.,  level  of  detail)  of  the 
modeled  system  components  and  processes  to  satisfy 
specific  requirements.  In  other  words,  for  a  given 
simulation  study,  we  often  need  to  increase  the  fidelity  of 
system  components  critical  to  the  “system  under  study” 
while  simultaneously  reducing  the  fidelity  of  components 
that  minimally  affect  that  system.  This  is  done  to  avoid 
complicating  the  analysis  with  unnecessary  detail  and 
reducing  the  simulation  time. 

The  simulation  also  needs  to  be  understandable  and 
easily  configured  by  end  users,  who  are  typically  not 
computer  programmers,  yet  provide  enough  flexibility  to 
model  and  evaluate  the  many  different  components  and 
processes  of  QKD  systems.  From  a  software  engineering 
perspective,  this  implies  the  development  of  a  common 
reusable  simulation  capability  (i.e.,  framework)  that 
includes  abstract  models  to  support  the  development  of 
system  components  and  implementations. 

Because  QKD  is  a  relatively  new  technology,  changes  in 
hardware,  software  and  processes  used  to  implement  a 
system  frequently  occur,  even  within  currently  available 
commercial  offerings.  A  robust  simulation  capability  needs 
to  facilitate  modeling  these  changes  quickly,  efficiently, 
and  without  requiring  the  user  to  have  significant 
programming  expertise. 

Finally,  everything  has  an  associated  cost.  While 
modeling  and  simulation  is  much  cheaper  than  the 
acquisition  and  testing  of  real  QKD  systems,  it  runs  the  risk 
of  not  having  enough  resources  committed  to  the  project, 
which  can  result  in  a  capability  inadequate  for  its  task  [6]. 


Given  the  diversity  of  QKD  implementations,  and  the 
desire  for  a  common  set  of  abstractions  to  support 
modelling  at  different  levels  of  fidelity,  two  clear  ‘end’ 
users  can  be  identified;  software  developers  and  system 
engineering  analysts.  Requirements  focused  on 
accommodating  an  analyst  tend  toward  the  interface 
‘friendliness’  and  configuration  flexibility  that  selects  and 
exposes  model  functionality  without  resorting  to  “software 
level”  programming  concerns.  Requirements  that  are 
oriented  more  towards  developers  include  the  architectural 
features  of  the  application  itself,  abstractions  flexible 
enough  to  model  components  at  many  levels  of  detail,  and 
inherent  capabilities  to  create  ‘friendly’  interfaces  for  the 
analyst. 

A  consultation  with  Subject  Matter  Experts  (SMEs)  in 
the  fields  of  optical  physics  and  a  review  of  simulation 
software  literature  identified  four  major  requirements  areas 
for  the  end  user:  technical,  usability,  flexibility,  and  Total 
Cost  of  Ownership  (TCO).  Each  area  has  multiple  sub¬ 
requirements/criteria,  many  of  which  were  derived  using 
Banks’  advice  for  evaluating  and  selecting  simulation 
software  [6],  the  best  practices  report  for  the  Department  of 
Defense  (DOD)  Modeling  and  Coordination  office  [7],  and 
the  [8]  European  Space  Agency  (ESA)  guide  to  user 
requirements  [8].  Table  I  identifies  the  relevant  technical 
end  user  requirements.  Table  II  identifies  relevant  usability 
end  user  requirements.  Table  III  identifies  relevant 
flexibility  requirements,  and  Table  IV  identifies  relevant 
TCO  end  user  requirements. 


TABLE  I 

End  User  Capability  Requirements  (Technical) 


Capability 

Notes 

Levels  of  fidelity 

Does  it  support  differing  levels  of 
model  fidelity? 

Execution  speed 

Does  it  have  fast  execution  (native 
C-I-+  is  used  as  a  fast  benchmark)? 

General 
programming 
languages  interface 

Does  it  interface  with  general 
programming  languages  such  as  C, 
C-H-,  and  Java? 

Input  flexibility 

Does  it  accept  data  from  external 
files,  databases,  spreadsheets,  and 
interactively  from  the  user? 

User-built  custom 
objects 

Can  users  build  and  reuse  objects, 
templates,  and  submodels? 

Model  status  and 
statistics 

Can  it  display  data  at  any  specified 
time  during  the  simulation? 
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The  list  of  relevant  developer  requirements  is  contained 
in  Table  V. 


TABLE  III 

End  User  Capability  Requirements  (Elexibility) 


TABLE  IV 

End  User  Capability  Requirements  (Total  Cost  of  Ownership) 


III.  Selecting  A  Simulation  Solution 

In  this  section,  we  briefly  review  different  types  of 
simulation  paradigms,  the  problem  sets  best  addressed  by 
each  paradigm,  and  best  practices  in  modelling  and 
simulation.  Several  seminal  papers  reaching  back  to  the 
1960s  were  identified  during  our  literature  search  [9-13].  A 
review  of  the  modeling  and  simulation  literature  provided 
guidance  on  general  criteria  to  consider  when  selecting  a 
simulation  solution  [14-23].  These  criteria,  in  conjunction 
with  our  QKD  domain  knowledge,  were  used  for  the 
evaluation  of  end  user  and  developer  requirements. 

Identifying  and  selecting  the  “type”  of  simulation  was 
the  first  step  in  the  selection  of  a  simulation  solution. 
Cassandras,  Banks  and  Fishman  all  have  [24-26] 
decompositions  of  simulation  systems  that  provide  some 
guidance  in  making  this  decision.  Figure  1  shows 
Cassandras’  version  of  the  decomposition  [24]. 


Capability 

Notes 

Required  operating 
system 

Is  it  free  from  specific  operating 
system  requirements? 

Required  platform 
software 

Is  it  free  from  required  pre¬ 
installed  software  packages? 

Documentation  available 

Is  there  documentation 
available  from  the  package 
developer? 

Software  developer 
support 

Does  the  developer  respond  to 
support  requests? 

Cost  of  simulation 
software 

Is  it  free  or  have  very  low 
procurement  costs? 

Licensing  fees 

Is  it  free  or  have  very  low  non¬ 
commercial  licensing  fees  for 
use  of  the  software? 

Training  costs 

Is  available  training  free  or  at 
very  low  cost? 

Required  hardware 

Does  the  software  have  minimal 
specific  required  hardware? 

Capability 

Notes 

Modular 

capability /composability 

Can  internal  code  modules  be 
linked  together  to  form  new 
constructs? 

Reconfigurable 

Can  users  change  the 
parameters  of  a  test  run? 

Time  variable 

Can  it  run  simulations  at 
varying  sim-time  speeds? 

Portability 

Can  it  be  used  on  different 
OS/hardware  platforms? 

TABLE  V 

Developer  Capability  Requirements 


Capability 

Notes 

Framework  vs.  specific 
platform 

Is  it  a  general  development 
platform  rather  than  a  specific 
topic  modeling  package? 

Interactive  internal 
debugger 

Does  it  have  a  built-in 
debugger? 

Graphical  programmer 
interface 

Does  it  have  a  built-in  graphical 
programmer  interface? 

General  programming 
languages  interface 

Does  it  interface  with  general 
programming  languages  such  as 
C,  C-I-I-,  and  Java? 

Extended  library  of  add¬ 
ons 

Is  there  an  extended  library  of 
add-ons  available? 

Third-party  support 

Do  3rd  parties  support  the 
software? 

Specific  working 
environment 

Does  it  need  other  software  for 
development  purposes? 

Mature  softwai'e 
documentation 

Is  there  mature  documentation 
(written  by  developer,  printed, 
searchable)  available? 

Third-party 

documentation 

Is  there  3rd  party 
documentation  available 
(books,  papers,  how-tos, 
videos)? 

Randomness 

Does  it  have  a  built-in  pseudo¬ 
random  number  generator? 

Hybrid 

Can  it  handle  mixed 
continuous-time  and  discrete¬ 
time  models? 

TABLE  II 

End  User  Capability  Requirements  (Usability) 


Capability 

Notes 

Statistical  analysis 

Does  it  have  built-in  statistics 
functions  for  output? 

Graphical  interface 

Does  it  have  a  native  graphical 
interface? 

Documentation 

support 

Does  the  simulation  software  have 
user’s  guides,  etc.? 

Reports  function 

Does  it  have  built-in  reports  that 
can  be  changed  by  the  user? 

Output  export 

Can  it  output  to  many  different 
file  types? 

Training  available  for 
simulation  software 

Does  the  developer  or  3rd  party 
provide  training? 

User  community 
available 

Is  there  a  robust  and  open  user 
community  for  the  software? 
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Figure  1.  Major  simulation  type  classifications  [24]. 


A  major  characteristic  of  the  modelling  and  simulation 
of  QKD  systems  is  that  during  the  simulation  of  system 
operation,  hundreds  of  millions  of  optical  pulses  will  be 
generated  and  propagated  through  the  system.  While  each 
pulse  is  most  accurately  represented  as  a  continuous-time 
waveform,  it  is  computationally  infeasible  to  model  a 
complete  QKD  system  using  continuous -time  simulation. 
This  is  analogous  to  the  problem  of  modelling  a 
microprocessor  which  contains  millions  of  logic  gates. 
While  each  type  of  logic  gate  may  be  simulated  in  great 
detail  using  continuous-time  simulation  (e.g.,  using  SPICE 
[27]),  the  simulation  of  a  complete  microprocessor  is 
conducted  using  a  more  abstract,  event-based 
representation  (e.g.,  using  Verilog  [28])  based  upon 
parameters  extracted  from  more  detailed  simulations. 
Similarly,  our  approach  is  to  model  optical  pulses  as 
abstract,  parameterized  objects.  In  this  way,  we  can 
manipulate  the  parameters  of  the  optical  pulse  when 
implementing  simple  transforms  such  as  attenuation  or 
reconstruct  the  continuous -time  optical  pulse  waveform 
when  necessary  in  order  to  implement  complex  transforms 
such  as  interference. 

Using  the  definitions  provided  by  Cassandras  with  our 
understanding  of  the  unique  properties  of  the  QKD  systems 
we  wish  to  model,  we  determined  the  appropriate  type  of 
simulation  system  as  follows: 

•  Static  vs.  Dynamic  -  in  dynamic  systems  the  current 
output  values  depend  on  past  values;  all  QKD  systems 
use  past  output  data  to  determine  current  output 
values. 


•  Time-varying  vs.  Time-invariant  -  the  behavior  of 
time-invariant  systems  do  not  change  with  time. 
While  the  behavior  of  a  QKD  system  does  change  as 
a  function  of  time,  at  the  lowest  level  we  choose  to 
treat  this  temporal  behavior  using  very  short  discrete 
time  steps  during  which  the  system  will  change  very 
little.  Therefore,  we  treat  the  desired  simulation 
solution  as  time-invariant  during  each  discrete  time 
step  but  allow  changes  in  system  behaviour  between 
time  steps. 

•  Linear  and  Non-linear  Systems  -  in  linear  systems  the 
output  depends  linearly  on  the  input,  while  in 
nonlinear  systems  the  output  is  not  a  linear  function  of 
the  input.  QKD  is  not  a  linear  process  since  some  of 
the  quantum  processes  involved,  such  as 
measurement,  are  not  linear. 

•  Continuous-state  vs.  Discrete-state  systems  -  discrete- 
state  system  variables  are  elements  of  a  discrete  set. 
In  contrast,  continuous-state  variables  may  take  on 
any  state  value.  When  simulating  continuous-state 
QKD  functions  using  a  classical  computer,  these 
functions  are  ultimately  described  by  a  finite  set  of 
numbers.  For  example,  consider  the  range  of  possible 
values  of  a  signed  decimal  number  using  a  64-bit 
binary  representation.  While  the  set  of  possible  values 
is  quite  large,  it  is  from  a  countable  finite  discrete  set. 

•  Time-drive  vs.  Event-driven  -  event-driven  systems 
only  change  when  asynchronously  generated  discrete 
events  occur.  The  propagation  of  optical  pulses 
through  QKD  systems  can  be  described  efficiently 
using  a  series  of  scheduled  discrete-time  events. 

•  Deterministic  vs.  Stochastic  systems  -  stochastic 
systems  result  when  any  of  the  variables  are  random. 
QKD  is  an  inherently  random  process. 

•  Discrete-time  vs.  Continuous-time  -  discrete-time 
systems  have  one  or  more  variables  that  are  defined 
only  at  discrete  points  in  time,  usually  the  result  of 
some  type  of  sampling  process.  QKD  systems  could 
be  described  by  either  system,  but  a  discrete -time 
system  has  far  less  overhead  and  any  continuous -time 
system  can  be  considered  a  discrete-time  system  if  the 
time  period  is  small  enough. 

Based  upon  how  we  intend  to  model  system 
components,  we  select  a  dynamic,  time-invariant,  non¬ 
linear,  discrete-state,  event-driven,  stochastic,  discrete-time 
simulation  as  the  appropriate  simulation  type.  According  to 
Cassandras,  this  type  of  simulation  system  is  classified  as  a 
Discrete-Event  System  (DES)  as  shown  in  Figure  1 . 
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Selecting  a  simulation  solution  that  supports  the  DES 
modeling  paradigm  is  the  first  discriminator  to  narrow 
simulation  solutions  under  consideration.  Another  primary 
discriminator  in  selecting  a  simulation  solution  is  the  cost 
of  the  solution,  which  is  a  key  end  user  requirement.  While 
commercial  tools  may  offer  advanced  modelling 
capabilities  and  toolkits,  they  also  come  with  associated 
expenses.  As  a  consequence,  we  focused  on  candidate  DES 
solutions  that  were  either  considered  free  or  open-source. 
Eor  comparison,  we  did  include  commercial  tools  that  are 
commonly  used  in  mathematically  intensive  system 
modeling  endeavours  in  the  study. 

The  initial  selection  of  candidate  simulation  solutions 
was  driven  by  a  review  of  available  packages  identified 
through  Internet-based  searches.  After  reviewing  multiple 
sources  that  listed  or  evaluated  DES  software,  a  short  list  of 
such  software  became  the  open-source  pool  of  candidates. 
We  used  the  following  criteria  to  justify  further  evaluation 
of  the  open-source  candidates: 

•  Still  in  use  (actively  developed) 

•  Source  code  availability 

•  Eree  or  low  cost 

The  first  criteria  ensured  that  we  avoided  abandoned 
software  projects  without  any  obvious  support  or  continued 
development.  The  second  and  third  criteria  came  from 
discussion  with  SMEs  and  the  literature  review.  Source 
code  availability  enables  more  developmental  freedom  in 
creating  a  simulation  capability  suited  to  evaluate  QKD 
systems.  The  ‘free  or  low-cost’  requirement  lowers  the 
cost  to  end  users,  a  major  consideration  when  commercial 
software  packages  can  cost  in  the  tens  of  thousands  of 
dollars  and  may  have  substantial  yearly  maintenance  fees. 

The  other  half  of  the  pool  included  several  Commercial- 
Off-The-Shelf  (COTS)  software  products.  Considering 
these  products  enabled  us  to  evaluate  how  well  the  open- 
source  offerings  measured  up  against  the  commercial 
products  using  the  selected  criteria.  The  purpose  was  to  see 
if  there  were  any  critical  functional  capabilities  included  in 
COTS  products  that  were  not  available  in  free,  open  source 
solutions.  It  also  helped  to  clarify  and  understand  the  value 
offered  by  commercial  vendors  and  solutions.  One  could 
assume  that  since  commercial  products  have  more 
dedicated  paid  resources  to  enhance  products  than  a  typical 
open-source  project,  the  quality  and  capabilities  of  products 
might  trump  free  open  source  solutions.  A  possible  counter 
argument  to  that  assumption  is  that,  due  to  the  lack  of 
source  code  availability,  fewer  developers  can  take  part  in 
the  development  process  to  enhance  the  product  and  correct 
problems  (i.e.,  bugs).  The  development  of  Linux  strongly 
supports  the  counter  argument  for  operating  systems. 


The  COTS  products  selected  for  this  evaluation  included 
popular  packages  in  the  engineering  and  physical  sciences 
(e.g.,  MATLAB/Simulink,  Mathematica)  along  with  other 
dedicated  simulation  packages  (e.g.,  OpNet,  SimulS, 
Arena). 

What  follows  is  the  list  of  chosen  packages,  starting  with 
the  low-cost/free  packages: 

A.  Ptolemy  11  [29] 

Ptolemy  II  is  an  open-source  framework  using  an  actor- 
oriented  philosophy  available  from  the  University  of 
California,  Berkeley.  Each  actor  is  a  base  unit  and 
communicates  through  messages.  Actors  joined  together 
hierarchically  build  a  larger  structure  known  as  a  model.  In 
each  model,  there  is  a  component  called  as  director  which 
sets  the  semantics  of  the  model  and  executes  the  algorithm. 

B.  SimPy  [30] 

Simulation  in  Python  (SimPy)  is  a  DES  framework  for 
the  Python  programming  language.  It  provides  components 
for  processes,  customers,  messages,  and  resources.  It 
includes  internal  variables  to  monitor  and  gather  statistics 
and  provides  random  variates.  It  has  data  collection,  a  built- 
in  Graphical  User  Interface  (GUI)  and  plotting  functions 
and  is  capable  of  interfacing  with  other  Python  packages  to 
extend  its  capabilities.  A  community  of  developers  created 
and  maintain  SimPy. 

C.  C++Sim  [31] 

C-H-Sim  is  a  C-H-  library  for  the  C-H-  programming 
language  available  from  Norwich  University.  It  provides  a 
DES  framework  providing  simulation  routines,  random 
number  generators,  queuing  algorithms  and  thread  package 
interfaces.  It  provides  statistics  gathering  routines, 
debugging  classes,  test  routines  and  is  compatible  with  both 
C-H-  and  Java.  The  project  appears  to  be  migrating  from 
C-H-Sim  to  JavaSim. 

D.  Adevs  [32 ] 

Adevs  (A  Discrete-EVent  System  simulator)  is  a  C-H- 
library  maintained  by  the  Oak  Ridge  National  Laboratory. 
It  is  based  on  the  Parallel  DEVS  and  Dynamic  DEVS 
(dynDEVS)  formalisms  from  Zeigler  [33].  Adevs  links  to 
an  external  compiler  (OpenModelica  from  the  Modelica 
modeling  language)  and  supports  Java. 

E.  OMNeT++ [34] 

OMNeT-H-  is  component-based  C-H-  simulation  library 
and  framework  for  building  network  simulations. 
OMNeT-H-  includes  an  Eclipse-based  Integrated 
Development  Environment  (IDE)  tailored  to  support 
OMNeT-H-based  model  development. 
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It  includes  extensions  for  real-time  networks,  network 
emulation,  other  programming  languages  (C-H-  and  Java) 
and  database  integration.  It  appears  that  a  relatively  large 
community  supports  OMNeT-H-  development. 

F.  Arena  [35] 

Arena  is  a  COTS  DBS  from  Rockwell  Automation.  It  is 
designed  for  stochastic  processes  using  statistical 
distributions  through  curve  fitting.  Random  sampling 
allows  for  event  creation  and  processing  over  time.  Only 
registered  users  of  the  software  may  access  the  program 
documentation,  leading  to  largest  degree  of  uncertainty  in 
the  analysis. 

G.  MATLAB/Simulink  [36] 

Simulink  is  an  add-on  package  for  Math  Work’s 
MATLAB  computation  language  program,  necessitating 
buying  both  programs.  Simulink  uses  a  block  diagram  style 
to  assemble  hierarchal  models.  It  includes  a  graphical 
editor,  user-customizable  block  libraries  and  math-based 
solvers  for  dynamic  systems.  It  can  use  existing  MATLAB 
algorithms  and  computations  and  Simulink  results  can  be 
imported  into  MATLAB  for  analysis. 

FI.  Mathematica  [37] 

Mathematica  is  a  computational  language  program  from 
Wolfram  Research.  Much  like  MATLAB,  its  primary 
purpose  is  to  compute  mathematical  results.  While  not 
precisely  a  DBS -based  environment,  it  can  be  adapted  to 
provide  most  DBS  capabilities. 

I.  SimulS  [38] 

SimulS  is  from  SimulS  Corporation,  a  company  that 
produces  only  simulation  software.  SimulS  provides 
processing  of  discrete  entities  as  a  tool  for  planning,  design, 
optimization  and  engineering.  It  uses  dynamic  DBS  and 
includes  a  GUI,  statistical  tools,  and  reports  functions.  It  is 
designed  only  for  the  Windows  operating  environment,  but 
can  be  used  on  other  platforms  using  software  emulators. 

J.  OpNet  [39] 

OpNet  is  a  communication  network  simulator  from 
Riverbed  Technologies.  It  provides  advanced  toolsets  to 
model  networks  but  can  be  adapted  to  other  network-type 
models.  It  has  a  mature  set  of  libraries  and  add-on  tools 
using  object-oriented  modeling.  It  can  use  DBS  and  hybrid 
model  simulations  in  parallel  and  grid-computing 
environments  and  can  interface  with  live  systems.  It  has  a 
GUI  and  an  internal  debugger. 


It  is  important  to  note  that  while  there  are  many  more 
software  packages  available,  the  ones  listed  above  were 
chosen  as  representative  of  the  field,  with  a  focus  on  those 
typically  used  in  an  academic  setting. 

IV.  Bvaluating  Simulation  Solutions 

Bach  criterion  is  written  to  supply  a  binary  solution  (“Y” 
or  “N”)  rather  than  a  variable  answer  (such  as  a  Likert 
scale).  While  most  criteria  are  listed  in  just  one  section, 
there  are  several  that  appear  in  multiple  sections,  indicating 
their  importance  to  different  capabilities  (such  as 
documentation  and  cost  criteria).  The  evaluation  process 
consisted  of  the  following  steps: 

•  Bind  the  software  website  on  the  Internet. 

•  Bind  available  documentation  from  the 
developer/company. 

•  Review  3rd  party  websites  for  software  information. 

•  Search  for  3rd  party  literature. 

•  Read  through  available  information  for  each  package. 

•  Bvaluate  each  of  the  criteria  based  upon  the 
information  collected. 

The  preferred  source  of  information  is  the  software 
documentation,  but  in  several  cases  the  documentation  was 
not  readily  available.  In  this  case,  3rd  party  information  and 
other  information  from  the  developer  were  used  to  evaluate 
the  software. 

After  evaluating  the  criteria,  the  “Y”  and  “N”  answers 
were  entered  into  the  criteria  matrix  with  the  free/low-cost 
products  listed  first,  then  the  COTS  products.  A  “Y” 
answer  was  a  positive  result  and  colored  with  green.  A  “N” 
answer  is  considered  a  negative  result  and  colored  in  red. 
An  unknown  result  is  a  “?”  and  the  cell  colored  yellow  if 
no  determination  was  possible  from  the  available 
information. 

The  matrix  then  totaled  the  number  of  “Y”,  “N”,  and  “?” 
answers.  To  account  for  the  “?”  values,  each  software  was 
given  a  range  of  “Y”  values,  from  the  maximum  “Y”  to  the 
minimum.  The  maximum  “Y”  value  is  the  number  of  “Y” 
values  for  that  software  plus  the  number  of  “?”  values.  This 
allows  for  each  unknown  to  actually  be  a  positive  value. 
The  minimum  “Y”  is  the  “Y”  value  minus  the  “?”  value. 
This  is  the  worst  case  as  each  “?”  is  considered  a  negative. 
This  produces  a  range  of  “Y”  values  and  is  shown  in  the 
following  span  plots.  The  resulting  capability  evaluation 
matrices  are  shown  in  Tables  VI-XI. 
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TABLE  VI  TABLE  IX 

Project  Capability  Evaluation  Matrix  End  User  Capability  Evaluation  Matrix  (Flexibility) 


Ptolemy 

SimPy 

C++  Sim 

Adevs 

OMNeT++ 

Arena 

Simulink 

Mathematica 

SimulS 

OpNet 

Cost 

Y 

Y 

Y 

Y 

Y 

Source  code 
availability 

Y 

Y 

Y 

Y 

Y 

Modular 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Discrete  event 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Ptolemy 

SimPy 

C++  Sim 

adevs 

OMNeT++ 

Arena 

Simulink 

Mathematica 

SimulS 

OpNet 

Reconfigurable 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Time  variable 

Y 

Y 

7 

7 

Y 

7 

Y 

Y 

Y 

Portability 

Y 

Y 

Y 

Y 

Y  Y 

Y 

Y 

TABLE  X 

End  User  Capability  Evaluation  Matrix  (TCO) 


TABLE  VII 

End  User  Capability  Evaluation  Matrix  (Technical) 


Ptolemy 

SimPy 

C++  Sim 

adevs 

OMNeT++ 

Arena 

Simulink 

Mathematica 

SimulS 

OpNet 

Levels  of  fidelity 

7 

Y 

Y 

Y 

- 

■ 

V 

V 

■ 

- 

Execution  speed 

Y 

Y 

Y 

7 

Y 

Y 

9 

9 

Programming 
languages  interface 

Y 

Y 

Y 

Y 

Y 

7 

Y 

■ 

Y 

Input  flexibility 

7 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

User-built  custom 
objects 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Model  status  and 
statistics 

Y 

Y 

7 

7 

Y 

Y 

Y 

Y 

Y 

Y 

TABLE  VIII 

End  User  Capability  Evaluation  Matrix  (Usability) 


Ptolemy 

SimPy 

C++  Sim 

adevs 

OMNeT++ 

Arena 

Simulink 

Mathematica 

SimulS 

OpNet 

Graphical  interface 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Documentation 

support 

Y 

1 

Y 

Y 

Y 

Y 

Y 

Y 

Reports  function 

V 

■ 

1 

■ 

V 

Y 

Y 

Y 

Y 

Y 

Output  export 

■ 

- 

Y 

Y 

Y 

Y 

Y 

Training  available  for 
simulation  software 

1 

■ 

1 

1 

Y 

Y 

Y 

Y 

Y 

User  community 
available 

1 

1 

1 

Y 

Y 

Y 

Y  Y 

TABLE  XI 

Developer  Capability  Evaluation  Matrix 


Ptolemy 

SimPy 

C++  Sim 

adevs 

OMNeT++ 

Arena 

Simulink 

Mathematica 

SimulS 

OpNet 

Interactive  internal 
debugger 

Y 

7 

Y 

Y 

Y 

Y 

Graphical  programmer 
interface 

Y 

7 

7 

7 

Y 

Y 

Y 

Y 

Y 

Y 

General  programming 
languages  interface 

Y 

Y 

Y 

Y 

Y 

7 

Y 

■ 

Y 

Extended  libraiy  of 
add-ons 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Third  party  support 

7 

Y 

Y 

Y 

Y 

Y 

Specific  working 
environment 

Y 

Y 

Y 

Y 

■ 

■ 

Mature  software 
documentation 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Third  party 
documentation 

Y 

Y 

Y 

Y 

Y 

Randomness 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Hybrid 

Y 

7 

Y 

Y 

7 

7 

Y 

7 

Y 

7 
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TABLE  XII 

Overall  Adjusted  Score  Matrix 


Ptolemy 

SimPy 

C++  Sim 

Adevs 

OMNeT++ 

Arena 

Simulink 

Mathematica 

SimulS 

OpNet 

#  of  "N" 

9 

10 

11 

9 

3 

9 

6 

8 

12 

6 

#  of  "Y" 

29 

28 

26 

28 

35 

25 

34 

31 

26 

32 

#of "?" 

2 

2 

3 

3 

2 

6 

0 

1 

2 

2 

Total 

40 

40 

40 

40 

40 

40 

40 

40 

40 

40 

Adjusted 

N:  {N+?) 

11 

12 

14 

12 

5 

15 

6 

9 

14 

8 

Adjusted 

Y:  (Y+?) 

31 

30 

29 

31 

37 

31 

34 

32 

28 

34 

max  Y 
("adjusted 
Y"-N) 

22 

20 

18 

22 

34 

22 

28 

24 

16 

28 

min  Y  (Y- 
"adjusted 
N") 

IS 

16 

12 

16 

30 

10 

28 

22 

12 

24 

A  span  matrix  used  the  criteria  scores  from  Table  XII  to 
indicate  how  various  packages  compared.  The  number  of 
“Y”  answers  from  Table  XII  is  on  the  X-axis,  with  the 
software  packages  on  the  Y-axis.  Each  row  shows  the 
spread  of  possible  “Y”  answers  as  solid  span  of  color.  The 
larger  the  number  of  unknown  answers  from  Table  XII,  the 
larger  the  span  for  that  software. 


TABLE  XIII 

Capabilities  Adjusted-Y  Evaluation  Span  Matrix 


Mia 

Max 

Ptolfmy 

17 

21 

_ 

. 

&iaPy 

16 

20 

: 

IT 

. 

C-H-stn 

11 

17 

•deNt 

15 

21 

_ 

OMNeT— 

29 

33 

Are™ 

9 

21 

SmiiUink 

27 

27 

: 

1 

: 

M^benlic. 

21 

23 

SoiiiilS 

11 

15 

opNet 

23 

27 

V.  Analysis  Of  Results 

The  results  of  this  evaluation  process  indicate  that  the 
OMNeT-H-  simulation  framework  ranked  highest/first  -  it 
even  fared  better  than  commercial  offerings.  For  this  initial 
evaluation  or  screening  process,  the  result  is  not  surprising. 
In  fact,  it  can  be  argued  that  any  screening  process  such  as 
this  is  inherently  biased  (in  a  good  way)  towards  the 
solution  that  best  meets  the  requirements.  In  other  words, 
the  process  of  establishing  the  very  selection  criteria  itself 
helped  illuminate  some  of  the  driving  requirements  of 
special  important  or  of  particular  concern.  For  example, 
the  cost  of  providing  an  end  user  the  simulation  was  of 
particular  concern.  Because  of  that,  several  criteria 
represent  this  concern  by  breaking  costs  out  into  different 
categories  such  as  initial  software  and  licensing  fees. 

Nevertheless,  we  consider  OMNeT-H-  a  good  choice 
regardless  of  cost  due  to  other  technical  concerns  related  to 
modeling  QKD  systems  that  didn’t  necessarily  show  up  in 
the  initial  screening  process  -  some  of  these  are  as  follows. 

OMNeT’s  DES  provides  support  to  freely  intermix  the 
modeling  of  system  features  built  upon  different 
worldviews  and  paradigms;  For  example,  we  model  QKD 
components  and  systems  using  several  worldviews 
including  “event-driven”  to  capture  the  dynamics  of  pulse 
propagation  through  optical  components  and  fiber  cable; 
“process-based”  to  capture  and  represent  complex  software 
processes  (or  process  flows)  that  execute  or  perform  a 
series  of  related  operations  over  time  (e.g.,  QKD 
protocols);  and  the  “object-oriented”  that  enables  us  to 
define  standalone  software  components  that  can  be 
individually  tested,  assembled  and  interconnected  to  form 
complete  unique  system  architectures. 

OMNeT  also  provides  a  substantial  amount  of  well- 
written  documentation  and  has  a  vibrant  active  user 
community,  which  were  important  considerations  in  our 
initial  selection  criteria.  For  other  modeling  concerns,  the 
need  for  sophisticated  mathematical  capabilities,  such  as 
those  available  in  packages  such  as  MATFAB  and 
Mathematica,  are  simply  not  required  -  the  standard  math 
functions  and  capabilities  available  in  almost  any 
programming  language  was  found  sufficient  to  define  the 
effects  of  interest  (e.g.,  how  an  optical  component  affects 
an  optical  pulse).  Other  concerns  related  to  supporting 
simulations,  such  as  systematically  changing  input  factors, 
executing  replications,  collecting  data  and  the  subsequent 
data  analysis  were  found  to  be  sufficiently  provided  for  in 
OMNeT. 
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VI.  Conclusions 

The  intent  of  the  evaluation  process  highlighted  in  this 
paper  was  to  select  a  simulation  solution  that  supports  DBS 
modeling  concepts  with  respect  to  the  simulation  of  QKD 
systems.  A  portion  of  this  effort  was  to  identity  the 
necessary  requirements  for  such  a  simulation  and  to 
conduct  a  search  to  select  the  best  possible  simulation 
software  that  meets  the  requirements. 

The  research  considered  different  software  packages  and 
selected  the  OMNeT-H-  open-source  software  as  the  best 
choice  for  use  in  the  development  of  a  QKD  simulation 
framework.  Using  a  different  set  of  requirements  and 
considerations  may  result  in  a  different  selection. 

Further  research  is  in  progress  and  involves  creating  and 
documenting  a  conceptual  model  for  the  simulation  using 
modeling  formalism.  This  conceptual  model  will  be  the 
bridge  to  link  the  mathematical  models  provided  by  the 
SMBs  to  the  computer  code  created  by  the  project  coders  in 
OMNeT-H-.  The  conceptual  model  is  critical  in  creating 
well-defined  behaviors  for  the  simulation  and  increasing 
the  validity  of  the  simulation  model. 
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Abstract — Quantum  Key  Distribution  (QKD)  is  an  innovative  technology  which  exploits  the  laws  of  quantum  physics,  enabling 
two  parties  to  generate  shared  secret  cryptographic  key.  QKD  systems  offer  the  unique  advantage  of  being  able  to  detect  the 
presence  of  an  eavesdropper  during  the  key  generation  process  and  are  suitable  for  employment  in  applications  requiring  high 
security  such  as  those  found  in  financial,  government,  and  military  environments.  However,  QKD  is  a  relatively  nascent 
technology  and  real-world  systems  differ  significantly  from  theory  as  they  are  constructed  from  non-ideal  components.  The 
impact  of  these  non-idealities  is  not  well  understood  due  to  the  complexities  of  physical  and  system-level  interactions.  In  this 
paper,  we  present  a  reference  architecture  to  enable  the  study  of  polarization  modulation-based  QKD  systems.  The  reference 
architecture  was  developed  based  on  available  product  specifications,  reference  literature,  and  published  QKD  architectures 
and  is  described  to  provide  insight  into  how  QKD  systems  function.  The  reference  architecture  is  modeled  in  a  discrete  event 
simulation  framework  and  is  used  to  conduct  security  and  performance  analysis  to  inform  design  decisions  and  trade-offs. 

Index  Terms — Quantum  Key  Distribution;  Architecture;  Model  &  Simulation;  System  Design;  System  Analysis 
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1  Introduction 

Quantum  Key  Distribution  (QKD)  is  the  most  mature 
application  of  quantum  cryptography  and  heralded 
as  a  revolutionary  technology  offering  the  means  for  two 
parties  to  generate  secure  cryptographic  keying  material. 
Employing  the  laws  of  quantum  physics,  QKD  can  detect 
eavesdropping  during  the  key  generation  process,  where 
unauthorized  observation  of  quantum  communication 
induces  discernible  errors.  However,  QKD  is  a  nascent 
technology  where  real-world  systems  are  constructed 
from  non-ideal  components  which  adversely  impact  the 
security  and  performance  of  QKD  systems. 

In  this  article,  we  describe  a  QKD  reference  architec¬ 
ture  modeled  in  a  discrete  event  simulation  framework 
used  to  study  the  impact  of  these  non-idealities  and  prac¬ 
tical  engineering  limitations.  Moreover,  the  reference  ar¬ 
chitecture  provides  a  benchmark  system  to  gain  addition¬ 
al  understanding  and  study  critical  design  tradeoffs  asso- 
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ciated  with  interactions  between  physical  components 
and  system-level  considerations  (e.g.,  hardware,  software, 
and  protocols).  We  are  focused  on  bridging  the  gap  be¬ 
tween  QKD  theory  and  practice;  theoretical  and  experi¬ 
mental  physicists  are  working  towards  advancing  QKD 
technology,  but  few  are  strongly  focused  on  improving 
the  implementation  of  realized  systems.  We  are  using  the 
subject  architecture,  and  derivations  thereof,  to  more  fully 
understand  QKD  systems. 

In  Section  11,  we  provide  a  concise  background  focused 
the  development  of  the  first  QKD  protocol,  BB84.  In  Sec¬ 
tion  111,  we  introduce  the  discrete  event  simulation  capa¬ 
bility  used  in  this  work.  In  Section  IV,  we  describe  a  po¬ 
larization-based,  prepare-and-measure  BB84  QKD  refer¬ 
ence  architecture  and  describe  its  constituent  elements.  In 
Section  V,  we  present  conclusions  and  future  work  and 
an  Appendix  is  presented  containing  a  detailed  list  of  the 
modeled  QKD  optical  and  electro-optical  components 
and  their  primary  behaviors. 

2  Background 

The  genesis  of  QKD  can  be  traced  back  to  Wiesner,  who 
developed  the  idea  of  quantum  conjugate  coding  in  the 
late  1960s  [1].  He  described  two  applications  for  quantum 
coding:  1)  Quantum  Money:  a  method  for  the  creation  of 
fraud-proof  banking  notes,  and  2)  Quantum  Multiplex¬ 
ing:  a  method  for  transmitting  multiple  messages  in  such 
a  way  that  reading  one  of  the  messages  destroys  the  oth¬ 
er.  Charles  Bennett  and  Gilles  Brassard  subsequently  ex¬ 
ploited  this  concept  in  1984  when  they  proposed  the  first 
QKD  protocol  (BB84)  and  subsequently  built  their  first 
QKD  system  in  1989  [2], [3]. 
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2.1  QKD  System  Context 

In  order  to  provide  understanding  of  how  QKD  systems 
are  used,  we  present  a  QKD  system  context  diagram  as 
shown  in  Figure  1,  illustrating  a  QKD  system  consisting 
of  a  sender  "Alice",  a  receiver  "Bob",  a  classical  commu¬ 
nications  charmel  (i.e.,  Internet),  and  a  quantum  commu¬ 
nications  charmel  (i.e.,  a  dark  optical  fiber).  The  QKD  sys¬ 
tem  generates  a  shared  secret  cryptographic  key  K,  which 
is  consumed  by  Alice  and  Bob's  bulk  encryptors  and  used 
to  secure  a  communication  link.  In  the  scenario  depicted, 
a  plaintext  message  m  is  transformed  into  the  ciphertext 
Efiini)  by  the  bulk  encryptors  using  the  key  K,  transmitted 
over  the  high-speed  data  link,  and  decrypted  using  the 
key  K  at  the  distant  end  where  m=DK(EK(m)).  The  bulk 
encryptors  can  use  any  conventional  encryption  algo¬ 
rithms  including  DBS,  3DES,  or  AES. 

Users  desiring  increased  levels  of  information  protec¬ 
tion  may  use  the  QKD-generated  shared  secret  key  as  key 
material  for  a  One-Time  Pad  (OTP)  encryption  algorithm 
to  achieve  unconditionally  secure  communications  [4], [5]. 
However,  OTP  is  not  often  used  due  to  amount  of  key 
required  (i.e.,  equal  length  to  the  message)  and  security 
requirements  (i.e.,  the  key  is  random  and  never  re-used 
[5]).  QKD  systems,  when  properly  implemented,  consti¬ 
tute  one  of  the  most  significant  cryptographic  develop¬ 
ments  in  recent  history. 
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Plaintext  m 

Enciyptor 
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FIGURE  1.  QKD  System  Architecture  Context  Diagram.  Note:  addi¬ 
tional  administrative  and  control  signals  are  omitted  for  clarity. 

QKD  systems  primarily  use  two  basic  methods  for  en¬ 
coding  information  over  the  quantum  channel  [6].  In 
"prepare-and-measure"  protocols,  the  sender  and  receiv¬ 
er  use  matching  modulation  schemes  to  encode/ decode 
quantum  states  using  polarization-based  or  phase-based 
modulation  techniques.  In  "entanglement"  protocols,  two 
or  more  photons  are  inextricably  linked  and  are  described 
as  a  single  quantum  system,  where  a  measurement  on 
either  photon  affects  the  other.  In  this  paper,  we  focus 
solely  upon  the  BB84,  prepare-and-measure,  polarization- 
based  architecture  because  it  was  the  first  QKD  protocol, 
is  relatively  easy  to  understand,  and  remains  a  popular 
implementation  choice  for  QKD  systems  using  line-of- 
sight  "free  space"  direct  optical  links  necessary  for  future 
satellite  QKD  implementations  [7]. 

2.2  BB84  QKD  Protocol 

In  the  BB84  protocol,  Alice  prepares  quantum  bits  (qubits) 
by  encoding  information  onto  single  photons  using  one  of 
two  randomly  selected  conjugate  bases  (e.g.,  rectilinear 
and  diagonal)  and  a  randomly  selected  classical  bit  value 


(e.g.,  0  or  1)  as  illustrated  in  Figure  2.  Specifically,  Alice 
encodes  each  photon  using  one  of  the  four  the  polariza¬ 
tion  states  horizontal  (oscillating  between  0°  and  180°), 
vertical  (oscillating  between  90°  and  270°),  diagonal  (os¬ 
cillating  between  45°  and  -135°),  or  anti-diagonal  (oscillat¬ 
ing  between  -45°  and  135°).  She  then  transmits  the  qubit 
via  the  quantum  channel  to  Bob,  where  he  measures  the 
photon  using  a  randomly  selected  basis  (e.g.,  rectilinear 
or  diagonal).  Assuming  an  ideal  lossless  channel,  if  Bob 
measures  the  qubits  in  same  basis  as  Alice  used,  he  ob¬ 
tains  the  encoded  bit  value  with  a  high  degree  of  accura¬ 
cy.  However,  if  Bob  measures  the  qubit  in  the  incorrect 
basis,  a  random  result  will  be  obtained  and  all  previously 
encoded  information  is  lost.  This  is  due  to  the  quantum- 
level  interactions  necessary  for  measurement  to  occur, 
where  the  mere  act  of  measuring  an  encoded  quantum 
state  collapses  the  state  [8],  [9],  [10]. 
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FIGURE  2.  Example  BB84  Conjugate  Polarization  Bases:  Rectilinear 
and  Diagonal. 

Likewise,  if  an  eavesdropper  "Eve"  attempts  to  read 
qubits  on  the  quantum  channel,  she  necessarily  introduc¬ 
es  detectable  errors  because  she  does  not  know  the  encod¬ 
ing  basis  used  by  Alice  a  priori.  By  closely  monitoring  the 
error  rate  of  the  quantum  channel,  the  Quantum  Bit  Error 
Rate  (QBER),  allows  Alice  and  Bob  to  determine  if  an 
eavesdropper  is  present  during  the  key  generation  pro¬ 
cess.  By  encoding  qubits  in  two  conjugate  bases,  the  BB84 
protocol  provides  a  means  for  securely  distributing  cryp¬ 
tographic  key  based  on  the  laws  of  physics,  namely  quan¬ 
tum-level  uncertainties  [8], [9], [10]. 

2.3  BB84  Idealities 

The  BB84  protocol  assumes  several  idealities,  which  are 
not  realistic  or  practical  in  real  QKD  systems,  including 
[10],[11],[12],[13]: 

1)  On-demand  single  photon  sources  in  Alice 

2)  Perfect  single  photon  detection  in  Bob 

3)  A  lossless  quantum  channel  between  Alice  and  Bob 

4)  Perfect  basis  alignment  between  Alice  and  Bob 

If  these  conditions  are  met,  QKD  provides  provably  se¬ 
cure  key  exchange  [11], [12], [13].  However,  these  assump¬ 
tions  are  simply  not  valid  when  building  real-world  sys¬ 
tems.  Por  example,  reliable  on-demand  single  photon 
generation  is  not  currently  practical,  commercial  single 
photon  detectors  have  low  detection  efficiencies,  optical 
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fibers  have  well  understood  losses,  and  basis  alignment  is 
limited  by  the  accuracy  of  compensation  mechanisms. 

To  study  these  non-idealities  and  similar  practical  en¬ 
gineering  limitations,  we  developed  a  specialized  simula¬ 
tion  framework  to  enable  efficient  modeling,  simulation, 
and  analysis  of  QKD  system  architectures. 

3  The  QKD  Simulation  Framework  (qkdX) 

We  have  developed  a  QKD  simulation  framework  (qkdX) 
to  enable  efficient  modeling  of  QKD  systems,  where  "fit- 
for-purpose"  QKD  system  representations  can  be  built  for 
extensive  analysis.  Practically  speaking,  this  capability 
allows  users  (e.g.,  engineers  or  analysts)  to  more  quickly 
model  QKD  systems,  enabling  security  and  performance 
analysis,  including: 

1.  Model  and  analyze  competing  QKD  implementa¬ 
tions  (e.g.,  variations  in  hardware  components  or 
software  processes) 

2.  Increase  understanding  of  the  security- 
performance  design  and  implementation  trade 
space  for  realized  QKD  systems 

3.  Determine  the  impact  of  non-idealities  and  practi¬ 
cal  engineering  limitations  in  QKD  architectures 

4.  Identify  interactions  between  physical  (quantum 
phenomenon,  temperature,  and  disturbances)  and 
system-level  interactions  (hardware  designs, 
software  implementations,  and  protocols) 

5.  Propose  and  assess  new  QKD  implementations  or 
protocols 

6.  Study  the  security  implications  of  different  pro¬ 
tocol  modifications  and  system  architectures 

7.  Model  and  study  free-space  and  space-based 
QKD  systems 

8.  Maximize  research  investments  and  developmen¬ 
tal  efforts  to  improve  implementations  (e.g., 
should  one  invest  research  capital  in  on-demand 
single-photon  sources  or  improved  single  photon 
detectors?) 

3.1  Modeled  Components 

A  list  of  modeled  optical  component  is  shown  in  Table  1 
and  described  further  in  the  Appendix.  Emphasizing  the 
practical  nature  of  our  research,  we  have  also  chosen  to 
utilize  commercially  available  optical  fiber  devices  and 
technologies  such  as  telecom  wavelength  lasers,  modula¬ 
tion  encoders,  and  standardized  optical  components  to 
model  QKD  systems.  Each  component  is  configured  with 
12-27  adjustable  performance  parameters  and  modeled  in 
an  event-driven  paradigm,  while  device  controllers  are 
modeled  in  a  process-based  paradigm.  In  total,  dozens  of 
design  decisions  and  assumptions  were  made  to  model 
these  devices  and  supporting  processes  based  on  product 
specifications  provided  in  the  Appendix  Reference  sec¬ 
tion,  available  reference  literature,  pertinent  publications, 
and  discussions  with  Subject  Matter  Experts  (SME)  in  the 
fields  of  quantum  physics,  electrical  engineering,  optical 
physics,  and  software  engineering. 


TABLE  1.  Modeled  Optical  Components. 
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3.2  qkdX  Design  Features 

Design  features  of  qkdX  include:  a  hybrid  discrete- 
continuous  modeling  approach  to  more  accurately  cap¬ 
ture  quantum  effects;  a  modular  design  to  allow  quick 
and  efficient  changes  to  the  system  under  study;  parame¬ 
terized  components  allowing  for  multiple  varying  in¬ 
stances;  and  composability  allowing  for  hierarchal  con¬ 
struction  of  complex  systems  from  simple  components. 

The  framework  is  designed  with  considerations  to 
support  multiple  qubit  encoding  schemes  (i.e.,  polariza¬ 
tion-based,  phase-based,  and  entanglement),  multiple 
protocols  (e.g.,  BB84,  SARG04,  E92),  and  various  QKD 
applications  (e.g.,  buried  optical  fiber,  terrestrial  direc¬ 
tional  free-space  optical  link,  and  multiplexed  transmis¬ 
sions). 

3.3  qkdX  Simulation  Considerations 

Real-world  QKD  systems  often  use  existing  infrastruc¬ 
ture.  While  the  best  possible  quantum  channel  would  be  a 
dark  fiber  charmel,  QKD  implementations  may  time  mul¬ 
tiplexed  weak  signal  pulses  with  strong  telecommunica¬ 
tion  signal  over  the  quantum  charmel.  As  a  consequence, 
we  had  to  model  interference  and  scattering  effects  within 
the  optical  fiber  model.  Similarly,  as  an  optical  pulse 
propagates  through  an  optical  fiber,  it  becomes  attenuat¬ 
ed.  In  a  simulation,  it  is  important  to  define  a  threshold 
below  which  point  the  fiber  model  will  delete  the  optical 
pulse,  otherwise  pulses  will  continue  to  propagate  that 
are  below  useful  limits. 

Another  issue  requiring  special  attention  is  reflections. 
Each  time  a  pulse  enters  a  component,  a  small  portion  is 
reflected  in  the  opposite  direction  of  travel.  These  low- 
power  optical  packets  themselves  cause  additional  reflec¬ 
tions.  This  has  the  effect  of  creating  a  'reflection  storm'  of 
infinite  packets  bouncing  between  components  in  a  simu¬ 
lation.  To  handle  this  situation,  a  simulation  option  was 
created  to  enable  or  disable  reflections  on  a  per  compo¬ 
nent  basis. 

4  The  QKD  Reference  Architecture 

The  QKD  reference  architecture  serves  as  a  baseline  refer¬ 
ence  for  conducting  simulation  studies.  The  architecture 
was  developed  based  on  available  product  specifications, 
reference  literature,  and  published  QKD  system  designs 
including  [14], [15], [16], [17], [18].  A  survey  of  QKD  tech¬ 
nologies  is  provided  in  [19]. 
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4.1  Alice  and  Bob  Decomposition 

Our  prototypical  QKD  system  uses  a  polarization-based, 
BB84,  prepare  and  measure  architecture  as  shown  in  Fig¬ 
ure  3.  The  QKD  system  comprises  Alice,  Bob,  an  authen¬ 
ticated  public  communications  charmel  (classical  chan¬ 
nel),  and  a  quantum  communication  charmel  (quantum 
charmel).  Alice  and  Bob  include  a  system  controller,  a 
public  channel  controller,  and  a  quantum  module,  respec¬ 
tively.  The  focus  of  the  reference  architecture  is  the  quan¬ 
tum  communications  path  from  Alice  to  Bob,  the  other 
components  are  modeled  in  a  more  abstract  way.  The 
end-to-end  quantum  path  is  discussed  in  increasing  levels 
of  detail  throughout  the  remainder  of  Section  IV. 


FIGURE  3.  QKD  System  Ist-level  Decomposition. 


Alice  prepares  photons  with  candidate  secret  key  bits 
and  sends  them  to  Bob  via  the  quantum  charmel.  Bob  re¬ 
ceives  the  prepared  photons  and  measures  them  to  recov¬ 
er  the  candidate  key  bits.  Alice  and  Bob  coordinate  their 
system  operations  by  communicating  over  the  authenti¬ 
cated  classical  charmel. 

4.2  Alice  Subsystem  and  Quantum  Model 
Decomposition 

The  Alice  subsystem  contains  several  modules  including 
a  system  controller  module,  a  public  charmel  module,  and 
a  quantum  module  shown  in  Figure  3.  The  Alice  system 
controller  module  is  responsible  for  controlling  the  Alice 
subsystem  and  serves  as  the  master  controller  to  coordi¬ 
nate  operations  between  Alice  and  Bob.  The  public  chan¬ 
nel  module  interfaces  with  the  system  controller  module 
and  provides  connectivity  to  the  remote  system  via  the 
classical  charmel.  The  quantum  module  is  responsible  for 
generating  the  quantum  state  in  optical  pulses  before 
sending  them  to  Bob  via  the  quantum  charmel.  Alice's 
quantum  module  decomposes  into  nine  different  subsys¬ 
tems,  shown  in  FIGURE  4Figure  4. 


FIGURE  4.  Alice  Quantum  Module  Decomposition. 

The  relative  locations  of  the  DSG  module  and  CTQ 
module  are  significant  for  the  creation  of  decoy  states 
within  the  system.  This  is  a  necessary  security  measure  as 
the  DSG  creates  a  'vacuum'  and  a  'decoy'  state  [20]  within 
each  frame  as  a  protective  measure  against  the  Photon 
Number  Splitting  attack  [21],  a  significant  security  issue 
for  QKD  systems.  The  decoy  state  has  differing  levels  of 
photons  in  relation  to  the  normal  'signal'  state  but  the 


DSG  Electrically-controlled  Variable  Optical  Attenuator 
(EVOA)  applies  a  large  amount  of  attenuation  to  create 
the  vacuum  state,  removing  almost  all  of  the  photons. 
Creating  these  states  would  be  nearly  impossible  if  the 
pulses  travel  through  the  CTQ  module  and  attenuate  to 
quantum  levels  (generally  less  than  ten  photons)  before 
applying  the  varying  values  of  attenuation  to  create  the 
vacuum  and  decoy  states. 


TABLE  2.  Description  of  Alice  Quantum  Module  Subsystems 


Subsystem 

Function 

Classical  Pulse  Generator 
(CPG) 

Generates  a  multi-photon  pulse 

Polarization  Modulator 
(PM) 

Polarizes  the  photon  pulse  into  the 
desired  polarization 

Decoy  State  Generator 
(DSG) 

Creates  decoy  states  to  mitigate  pho¬ 
ton  splitting  attacks 

Classical  to  Quantum 
(CTQ) 

Converts  classical  laser  pulses  to 
quantum  levels  by  attenuating  to 
weak-coherent  levels 

Optical  Security  Layer 
(OSL) 

Detects  optical  probing  attacks 

Timing  Pulse  Generator 
(TPG) 

Generates  a  timing  pulse  used  for 
synchronization  and  multiplexes 
signal  and  timing  pulses 

Output  Power  Monitor 
(OPM) 

Monitors  the  output  optical  power 

The  variable  attenuators  in  the  DSG  and  CTQ,  both 
listed  in  the  block  diagrams  as  an  EVOA,  differ  signifi¬ 
cantly  in  their  usage.  The  DSG  EVOA  changes  quickly 
and  randomly  for  each  pulse  to  create  the  decoy  states. 
The  CTQ  EVOA  attenuates  the  laser  pulses  down  to 
quantum  level  and  will  only  change  in  response  to  output 
levels  measured  by  the  OPM  module.  Their  implementa¬ 
tion  and  purpose  is  very  dissimilar,  requiring  different 
performance  characteristics  and  requiring  the  simulation 
framework  to  have  unique  instances  of  particular  compo¬ 
nent. 


4.2. 1  Alice  Classical  Pulse  Generator  Subsystem 
Decomposition 

The  ideal  conceptual  model  of  a  QKD  system  specifies 
polarization-encoded  single  photons  with  the  desired  bit 
and  basis.  In  reality,  reliable  on-demand  single  photon 
pulse  generators  are  an  unrealized  technology.  Real- 
world  QKD  system  implementations  instead  generate  a 
laser  pulse  containing  millions  of  photons  and  strongly 
attenuate  the  pulse  down  to  statistical  sub-photon  (quan¬ 
tum)  levels.  Within  the  Alice  quantum  module,  the  CPG 
subsystem  generates  the  laser  pulses  and  shifts  them  into 
a  known  polarization.  The  CPG  subsystem  contains  the 
components  shown  in  Figure  5. 
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FIGURE  5.  Classical  Pulse  Generator  Subsystem  Decomposed. 


The  CPG  subsystem  components  include  a  controller 
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that  has  the  digital  and  analog  circuits  responsible  for 
controlling  the  laser  and  monitoring  the  classical  detector. 
The  laser  creates  optical  pulses  when  it  receives  a  "fire" 
command  from  the  controller  and  sends  them  to  the  isola¬ 
tor  via  special  polarization-maintaining  fiber  used  in 
components  that  cannot  have  drift  in  the  polarization 
state.  The  isolator  passes  light  in  the  forward  direction 
while  significantly  attenuating  light  moving  in  the  oppo¬ 
site  direction,  assuring  that  virtually  no  light  (e.g.,  reflec¬ 
tions  or  light  from  external  sources)  enters  the  laser.  The 
isolator  prevents  light  from  entering  the  laser  from  down¬ 
stream  component  reflections  (i.e.  the  polarizer)  and  from 
light  entering  Alice  from  the  quantum  charmel.  Extrane¬ 
ous  light  entering  the  lasing  cavity  can  create  perturba¬ 
tions,  causing  improper  output  waveforms  and  disrupt¬ 
ing  the  proper  formation  of  optical  packets 

The  polarizer  allows  light  of  one  polarization  to  pass 
while  highly  attenuating  orthogonal  light,  this  'cleans'  the 
laser  output  before  sending  the  light  to  the  bandpass  fil¬ 
ter.  This  filter  passes  optical  energy  in  a  narrow  band 
around  the  laser  signal  wavelength.  As,  ensuring  only  the 
appropriate  signal  wavelength  leaves  the  subsystem 
while  preventing  other  sources  of  light  from  entering  the 
laser.  The  light  enters  the  beamsplitter  and  is  split  into 
two  components.  The  beamsplitter  passes  99%  of  the 
pulse  to  the  next  quantum  module  subsystem  and  trans¬ 
mits  1%  of  the  pulse  to  the  classical  detector.  This  detector 
generates  an  electrical  signal  proportional  to  the  power 
contained  in  the  optical  and  allows  the  controller  to  de¬ 
termine  if  pulses  leaving  the  CFG  have  the  proper  optical 
power. 

4.2.2  Alice  Polarization  Modulator  Subsystem 
Decomposition 

The  polarization  modulator  creates  the  polarization 
encoding  necessary  for  the  BB84  protocol  by  polarizing 
the  optical  pulses  generated  by  the  CFG  laser.  Some  QKD 
systems  use  a  laser  for  each  polarization  value  (e.g.  four 
lasers),  but  this  architecture  uses  one  laser  and  a  polariz¬ 
ing  component  to  change  each  packet  polarization.  This 
design  decision  forced  the  creation  of  way  to  alter  the 
polarization  of  optical  packets,  creating  a  capability  that 
would  not  be  present  otherwise.  One  of  the  design  goals 
of  the  simulation  framework  is  to  build  capabilities  into 
the  framework  as  early  as  possible  to  provide  'building 
blocks'  for  later  architectures.  The  FM  subsystem  contains 
the  components  shown  in  Figure  6. 


FIGURE  6.  Polarization  Modulator  Subsystem  Decomposed. 


The  FM  subsystem  includes  a  controller  to  interface 
with  the  polarization  modulator.  Unlike  the  other  com¬ 
ponents  in  the  architecture,  the  polarization  modulator  is 
an  abstract  component  that  represents  any  number  of 


devices  used  to  electronically  change  the  polarization  of 
the  light  stream  from  a  known  polarization  to  one  of  sev¬ 
eral  output  polarizations.  The  optical  output  no  longer 
needs  the  polarization-maintaining  fiber,  so  the  output 
path  changes  to  single-mode  optical  fiber.  This  fiber  has  a 
core  that  guides  the  light  and  an  outer  cladding  that  re¬ 
flects  the  internal  light  back  into  the  core,  allowing  for 
low  loss  over  long  distances.  Its  low  loss  and  significantly 
cheaper  cost  than  polarization-maintaining  fiber  make  it 
suitable  for  telecommunication  networks  and  general 
fiber  optic  use. 

4.2.3  Alice  Decoy  State  Generator  Subsystem 
Decomposition 

The  ideal  version  of  a  QKD  system  would  emit  single 
photons,  but  existing  hardware  is  not  capable  of  produc¬ 
ing  on-demand  single  photons.  This  allows  eavesdrop¬ 
pers  the  opportunity  to  conduct  the  Fhoton  Number 
Splitting  (FNS)  attack,  but  Alice  and  Bob  have  counter¬ 
measures  in  the  decoy  states.  The  EVOA  inserted  into  the 
optical  charmel  allows  the  quantum  controller  to  random¬ 
ly  vary  the  power  of  the  optical  pulses,  allowing  creating 
of  the  various  states  (vacuum,  decoy  and  signal).  This 
variance,  along  with  statistics  collected  on  the  received 
states,  allows  Alice  and  Bob  to  detect  FNS  activity  in  the 
quantum  charmel.  Until  technology  develops  a  reliable 
on-demand  photon  emitter,  like  the  promising  research 
into  the  quantum  dot,  some  form  of  defense  against  the 
FNS  attack  is  a  must  for  QKD  systems.  The  EVOA  con¬ 
tains  the  components  shown  in  Figure  7. 


FIGURE  7.  Decoy  State  Generator  Decomposed. 

The  DSG  subsystem  contains  a  controller  for  the 
EVOA,  an  opto-electrical  device  containing  a  variable 
attenuator.  The  attenuator  is  usually  some  form  of  block¬ 
ing  material,  such  as  an  opaque  slab  or  a  window  tilted  in 
the  path  of  the  light,  connected  to  an  electric  motor.  As 
discussed  earlier,  the  selection  criteria  for  this  focuses  on 
power  attenuation  (bleed  around  the  blocking  material) 
and  motor  speed,  as  the  EVOA  needs  to  quickly  change 
between  settings  during  the  quantum  exchange.  Cost  vs. 
performance  will  be  a  major  decision  for  this  device.  The 
DSG  uses  single-mode  optical  fiber  for  both  input  and 
output  into  the  EVOA. 

4.2.4  Alice  Classical  To  Quantum  Subsystem 
Decomposition 

Optical  pulses  generated  by  the  laser  in  the  CFG  con¬ 
tain  millions  of  photons,  far  more  than  required  by  QKD 
protocols.  Since  single  photon  generators  are  not  availa¬ 
ble,  existing  QKD  systems  take  these  classical-level  pulses 
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(meaning  they  contain  many  photons)  and  attenuate  them 
to  quantum-level  pulses  (meaning  less  than  ten  or  so  pho¬ 
tons)  with  an  average  photon  count  of  0.1.  This  low  num¬ 
ber  is  necessary  to  achieve  the  single  photon  require¬ 
ments  of  QKD.  Until  single  photon  generators  become 
available,  many  QKD  protocols  need  both  the  DSG  and 
the  CTQ  submodules.  The  CTQ  subsystem  contains  the 
components  shown  in  Figure  8. 


FIGURE  8.  Classical  To  Quantum  Decomposed. 


The  CTQ  subsystem  contains  a  controller  and  an 
EVOA  much  like  the  DSG,  but  this  EVOA  does  not  need 
the  high-speed  motors  and  tight  attenuation  tolerances. 
The  CTQ  EVOA  changes  position  in  response  to  the  opti¬ 
cal  output  measured  in  the  final  module,  so  it  changes 
attenuation  much  less  rapidly.  The  EVOA  provides  a  fine- 
tuning  of  the  attenuation  applied  by  it  and  the  fixed  at¬ 
tenuator  to  bring  the  mean  photon  number  of  the  optical 
pulses  down  to  single  photon  levels.  The  attenuator  is 
usually  either  doped  fibers  or  misaligned  splices  de¬ 
signed  to  apply  a  fixed  attenuation  to  the  optical  pulses. 
All  of  the  interconnections  use  the  standard  single-mode 
fiber,  as  any  polarization  changes  are  corrected  at  Bob. 

4.2.5  Alice  Optical  Security  Layer  Subsystem 
Decomposition 

The  OSL  works  to  detect  and  limit  the  amount  of  out¬ 
side  light  entering  the  QKD  system.  The  bandpass  filter 
narrows  the  incoming  light  frequencies  and  the  circulator 
routes  the  incoming  light  to  the  classical  detector.  The 
detector  acts  as  the  'alarm'  by  creating  an  electrical  signal 
to  the  quantum  controller.  The  circulator  allows  very  little 
light  to  pass  from  port  one  to  three  and  any  that  does  is 
heavily  attenuated  by  the  isolator.  The  OSL  provides  pro¬ 
tection  against  an  adversary  shining  light  into  the  Alice 
box  and  discerning  information  about  the  internal  con¬ 
struction  by  evaluation  the  reflections,  protects  against 
high-power  pulse  attacks  meant  to  burn  out  interior  com¬ 
ponents,  and  prevents  most  random  frequency  light  from 
passing  back  towards  the  laser.  The  OSL  subsystem  con¬ 
tains  the  components  shown  in  Figure  9. 


FIGURE  9.  Optical  Security  Layer  Decomposed. 


Light  entering  the  OSL  from  outside  passes  through 
the  bandpass  filter,  which  filters  all  light  around  the  sig¬ 


nal  wavelength.  Any  light  managing  to  pass  through  fil¬ 
ter  enters  the  circulator,  which  routes  light  entering  it  in  a 
clockwise  direction,  and  impacts  the  classical  detector. 
The  detector,  usually  some  form  of  photo-diode,  gener¬ 
ates  a  signal  in  proportion  to  the  light  it  receives  to  the 
controller,  which  notifies  the  quantum  controller.  In  this 
way,  the  classical  detector  functions  as  an  alert  device. 

Any  light  that  bleeds  through  the  circulator  (a  very 
small  amount,  as  the  attenuation  is  greater  than  50dB) 
stops  at  the  isolator,  which  is  oriented  to  pass  light  out  of 
Alice.  This  isolator  applies  large  amounts  of  attenuation 
to  light  travelling  towards  the  laser,  effectively  stopping 
light  in  this  direction.  Any  light  travelling  from  the  laser 
out  of  Alice  passes  through  the  circulator  and  into  the 
bandpass  filter,  then  out  of  the  OSL,  via  single-mode  fiber 
interconnections. 


4.2.6  Alice  Timing  Pulse  Generator  Subsystem 
Decomposition 

The  optical  frames  used  by  the  QKD  system  need  a 
way  to  synchronize  between  Alice  and  Bob.  Even  the  best 
timing  devices  have  error  and  other  external  timing  (i.e. 
GPS)  do  not  have  the  accuracy  necessary  for  frame  tim¬ 
ing.  Bob  needs  to  know  with  a  high  degree  of  accuracy 
when  to  open  the  gates  windows  for  his  single  photon 
detectors.  Alice  provides  this  timing  by  injecting  a  bright 
pulse  (i.e.  classical-level)  of  light  into  the  quantum  chan¬ 
nel  to  start  each  frame,  followed  by  a  series  of  quantum- 
level  pulses.  Bob  uses  the  bright  pulse  as  a  timing  'hack' 
and  opens  and  closes  the  'gates'  of  his  detectors  to  best 
detect  the  quantum  pules.  Bob  uses  this  timing  infor¬ 
mation  when  communicating  with  Alice  to  during  sifting 
and  error  correction  of  the  raw  key  material  derived  from 
his  detections.  The  TPG  contains  the  components  shown 
in  Figure  10. 


FIGURE  10.  Timing  Pulse  Generator  Decomposed. 


The  TPG  subsystem  has  a  controller  and  laser  that 
work  the  same  as  in  the  CPG,  but  this  laser  produces 
pulses  on  a  timing  wavelength  slightly  different  than  sig¬ 
nal  wavelength.  The  two  wavelengths  have  to  be  close 
enough  to  pass  through  any  bandpass  filters,  but  far 
enough  apart  so  the  two  wavelengths  can  be  separated  in 
Bob.  The  polarizer  filters  out  any  extraneous  light  and  the 
fixed  attenuator  reduces  the  pulse  power  while  maintain¬ 
ing  classical  levels.  Finally,  the  signal  and  timing  pulses 
are  mixed  together  by  the  wave  division  multiplexor,  also 
known  as  a  dichroic  mirror,  and  send  via  single-mode 
fiber  to  the  next  submodule.  In  this  instance,  the  Wave 
Division  Multiplexer  (WDM)  mixes  the  two  signals,  but 
can  be  used  to  separate  signals,  as  we  see  in  Bob. 
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4.2.7  Alice  Output  Power  Monitor  Subsystem 
Decomposition 

Alice  needs  a  way  to  verify  her  output  into  the  quan¬ 
tum  channel  is  at  one  or  less  photons.  Pulses  with  more 
than  one  photon  are  subject  to  the  PNS  attack.  Compo¬ 
nents  change  as  they  age  and  some  protocols  may  call  for 
pulses  of  differing  optical  power.  The  OPM  allows  Alice 
to  sample  the  outgoing  optical  packets  by  using  a  photon 
detector  capable  of  counting  photons.  By  sampling  the 
photon  numbers,  Alice  can  adjust  the  CTQ  EVOA  to  out¬ 
put  the  proper  optical  power.  The  OPM  contains  the 
components  shown  in  Figure  11. 


FIGURE  11.  Output  Power  Monitor  Decomposed. 


The  OPM  subsystem  contains  a  controller  connected  to 
a  switch  and  the  photon  number  resolving  single  photon 
detector  (PNR-SPD).  The  optical  switch  is  used  to  route 
light  between  one  input  port  and  either  out  the  quantum 
channel  or  to  the  PNR-SPD.  The  PNR-SPD  is  an  opto- 
electrical  device  containing  detection  equipment  and 
support  electronics  capable  of  counting  individual  pho¬ 
tons. 

The  PNR-SPD  in  this  module  is  an  example  of  the 
need  to  test  the  framework  overriding  the  knowledge  of 
real  systems.  Alice  would  like  to  know  exactly  how  many 
photons  are  entering  the  quantum  channel,  and  the  PNR- 
SPD  gives  that  count,  but  these  devices  are  bulky  and 
very  expensive.  For  purposes  of  the  architecture,  includ¬ 
ing  this  device  exercises  the  framework  rather  than  repre¬ 
sent  real  systems.  In  real  systems,  these  devices  are  not 
present  (due  to  cost  and  size)  and  other  methods  are  used 
to  estimate  the  output  optical  power,  increasing  the  chance 
that  Alice  is  producing  multi-photon  packets,  enabling 
the  PNS  attack.  This  cost  vs.  security  trade-off  makes  the 
inclusion  of  the  DSG  (or  equivalent)  even  more  im¬ 
portant. 

4.3  Bob  Subsystem  Decomposition 

The  Bob  system  controller  operates  the  Bob  subsystem 
and  receives  commands  from  the  Alice  controller.  Bob's 
public  charmel  controller  works  just  as  Alice's,  providing 
a  pathway  for  authenticated  communications  over  the 
public  charmels.  Bob's  quantum  module  receives  and  de¬ 
tects  optical  pulses  over  the  quantum  charmel  and  has  no 
pulse-generating  components.  It  contains  timing  compo¬ 
nents  that  operate  its  gated  detectors  using  'bright'  pulses 
in  the  quantum  frames.  Bob's  quantum  module  decom¬ 
poses  into  five  subsystems,  shown  in  Figure  12. 
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FIGURE  12.  Bob's  Quantum  Module  Decomposed. 


TABLE  3.  Description  of  Bob  Quantum  Module  Subsystems 


Subsystem 

Function 

Input  Stage  (IS) 

Receives  the  photon  pulse 

Polarization  Adjustment  (PA) 

Adjusts  for  transmission  polari¬ 
zation  drift 

Wave  Division  Multiplexer 
(WDM) 

De-multiplexes  signal  and  timing 
pulses 

Polarization  Detector  (PD) 

Directs  photons  to  the  detectors 

Timing  Analyzer  (TA) 

Detects  photons  during  hmed 
gates 

Bob's  architecture  shows  many  differences  from  Alice. 
As  Bob's  purpose  is  to  receive  the  few  photons  that  make 
the  journey  from  Alice,  his  components  are  selected  to 
limit  the  attenuation  of  the  optical  signal.  Since  he  is  re¬ 
ceiving  single  photons,  every  bit  of  attenuation  is  signifi¬ 
cant.  In  Alice,  the  OSL  module  is  the  primary  security 
device  against  light  coming  into  her  system.  Bob's  Input 
Stage  acts  to  prevent  extraneous  light  from  entering  by 
only  admitting  a  narrow  band  of  frequencies  and  block¬ 
ing  light  entering  Bob  from  reflecting  back  outside.  These 
components  exhibit  very  small  attenuation  values,  mak¬ 
ing  them  a  good  choice  for  security  while  limiting  their 
effects  on  single  photons. 

4.3. 1  Bob  Input  Stage  Subsystem  Decomposition 
The  Input  Stage  acts  as  a  filter  for  incoming  light  into 
Bob,  as  the  bandpass  filter  allows  only  wavelengths  of 
light  around  the  timing  and  signal  frequencies  to  enter. 
The  isolator  allows  light  into  Bob,  but  prevents  most  light 
(mainly  reflections)  from  leaving  Bob.  This  provides  secu¬ 
rity  to  Bob  by  preventing  an  adversary  from  using  light 
probes  to  gain  information  about  internal  structure.  The 
Input  Stage  contains  the  components  shown  in  Figure  13. 


FIGURE  13.  Input  Stage  Decomposed. 


4.3.2  Bob  Polarization  Adjustment  System 
Decomposition 

Optical  packets  undergo  changes  in  polarization  as 
they  transit  the  quantum  channel.  This  polarization  drift 
comes  from  many  factors  (i.e.,  the  environment,  compo¬ 
nents,  and  reflections)  so  each  packet  needs  correction 
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before  entering  the  detectors.  The  polarization  controller 
adjusts  incoming  packets  based  on  the  timing  signal 
(bright  pulse)  received  from  Alice.  The  PA  subsystem 
contains  the  components  shown  in  Figure  14. 


FIGURE  14.  Polarization  Adjustment  Decomposed. 


This  submodule  is  very  simple  and  exists  only  to  sepa¬ 
rate  the  two  signals.  The  choice  of  the  WDM  depends  on 
the  timing  and  signal  frequencies,  which  need  to  be  close 
to  one  another  to  pass  through  the  bandpass  filters,  but 
far  enough  apart  to  be  separated  by  the  WDM  optics. 

4.3.4  Bob  Polarization  Detector  Subsystem 
Decomposition 

The  WDM  separates  the  TPG  timing  signal  At,  and  the 
CPG  signal  pulse  As.  Once  separated,  the  timing  pulses  go 
to  the  timing  controller  for  the  single  photon  detectors 
and  the  signal  pulses  output  to  the  Polarization  Detector 
submodule.  The  WDM  contains  the  components  shown 
in  Figure  16. 


The  PA  subsystem  contains  a  controller  cormected  to  a 
polarization  controller,  a  device  that  changes  the  polariza¬ 
tion  state  of  light  that  passes  through  it,  converting  light 
from  any  random  polarization  state  into  a  specific  output 
polarization  state.  It  consists  of  polarimeter  and  a  state  of 
polarization  (SOP)  controller  combined  with  a  computer 
and  software.  The  frame  of  reference  polarization  be¬ 
tween  Alice  and  Bob  is  set  when  the  system  is  installed, 
so  Bob  always  knows  what  polarization  values  to  expect 
from  Alice. 

While  this  device  can  change  the  polarization  to  any 
specific  point  on  the  Poincare  sphere,  it  has  a  response 
time  to  move  from  one  point  to  another  point.  If  the 
change  in  polarization  between  successive  frames  is  too 
great,  it  will  not  be  able  to  keep  up  and  the  output  polari¬ 
zation  will  not  be  correct.  Such  large  disturbances  are 
possible  if  the  quantum  channel  fiber  is  greatly  disturbed, 
such  as  aerial  fiber  being  moved  by  high  winds.  This  re¬ 
sponse  time  is  another  cost  vs.  performance  trade-off,  as 
faster  devices  cost  more  than  slower  devices.  The  builder 
would  have  to  take  into  the  account  the  expected  working 
environment  for  the  QKD  system.  The  still  uses  single¬ 
mode  fiber  at  this  point,  as  the  incoming  packets  should 
be  corrected  to  the  proper  polarization. 

4.3.3  Bob  Wave  Division  Multiplexer  Subsystem 
Decomposition 

This  WDM  separates  the  TPG  timing  signal  At,  and  the 
CPG  signal  pulse  As  into  two  streams,  reversing  the  mix¬ 
ing  done  by  the  WDM  in  Alice.  Once  separated,  the  tim¬ 
ing  pulses  go  to  the  single  photon  detectors  timing  con¬ 
troller  and  the  signal  pulses  output  to  the  polarization 
detector.  The  WDM  contains  the  components  shown  in 
Figure  15. 
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FIGURE  16.  Polarization  Detector  Decomposed. 

The  PD  subsystem  contains  a  bandpass  filter  which  fil¬ 
ters  the  incoming  frequencies  to  clean  the  signal  and  a 
beamsplitter  that  acts  to  randomly  send  single  photons  to 
the  output  ports.  One  port  leads  to  a  polarizing 
beamsplitter  that  directs  the  photon  based  on  its  polariza¬ 
tion  to  one  of  two  outputs  leading  to  the  Timing  Analyzer 
horizontal  and  vertical  detectors.  The  other  port  leads  to  a 
half-wave  plate  that  rotates  the  signal  by  45  degrees,  and 
then  to  a  second  polarizing  beamsplitter  that  outputs  to 
two  separate  channels  that  lead  to  the  antidiagonal  and 
diagonal  detectors  in  the  Timing  Analyzer.  Polarization- 
maintaining  fiber  connects  the  remaining  components 
after  the  beamsplitters. 

4.3.5  Bob  Timing  Analyzer  Subsystem  Decomposition 

The  TA  contains  single  photon  detectors  set  to  detect 
one  of  four  polarizations  (antidiagonal,  diagonal,  horizon¬ 
tal  and  vertical)  and  support  electronics.  The  single  pho¬ 
ton  detectors  need  to  be  'gated'  open  so  they  are  sensitive 
to  single  photons  but  then  close  to  reduce  the  number  of 
false  detections  (called  dark  counts).  The  classical  detector 
receives  the  timing  signal  from  the  WDM  and  creates  an 
electrical  signal  to  the  timing  controller.  The  timing  con¬ 
troller  uses  the  electrical  signal  from  the  classical  detector 
to  calculate  when  to  open  and  close  the  gates  of  the  detec¬ 
tors.  The  TA  contains  the  components  shown  in  Figure 
17. 


FIGURE  15.  Wave  Division  Multiplexer  Decomposed. 
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FIGURE  17.  Timing  Analyzer  Decomposed. 

The  timing  contioller  is  a  set  of  electronics  that  use  the 
electrical  signal  produced  by  the  classical  detector  to  send 
commands  to  the  SPDs  to  open  and  close  the  'gates.'  The 
critical  components  are  the  Single  Photon  Detectors 
(SPD),  which  are  opto-electrical  devices  operating  in  sev¬ 
eral  modes  and  use  signals  from  the  timing  controller  to 
change  modes.  These  'gates'  increase  the  sensitivity  of  the 
SPD  but  increase  the  chance  of  a  false  detection.  The  four 
detectors  correspond  to  the  four  polarization  choices  from 
Alice's  polarization  controller:  Diagonal,  Antidiagonal, 
Horizontal,  and  Vertical. 

A  design  decision  for  the  qkdX  framework  was  to 
model  all  optical  interference  calculations  in  the  SPD,  ra¬ 
ther  than  in  every  component.  This  choice  made  the  SPD 
far  more  complex  to  model  than  other  components  but 
concentrated  the  complexity  in  one  spot.  The  SPD  is  a 
critical  piece  of  real  QKD  systems,  as  the  detector's  ability 
to  recover  from  detections  determines  the  detection  rate 
over  any  time  period,  and  consequently,  the  number  of 
photons  the  SPD  can  detect.  Adding  in  other  considera¬ 
tions  for  the  component  means  it  has  many  more  perfor¬ 
mance  parameters  than  most  components,  each  one  add¬ 
ing  to  its  modeling  complexity. 

There  are  several  types  of  SPDs  and  the  selection  of 
what  particular  SPD  to  include  in  the  architecture  de¬ 
pends  on  the  intent  of  that  particular  simulation.  Some  of 
the  types  available  include  Avalanche  Photo  Diode 
(APD),  Superconducting  Nanowire  SPD  (SNSPD),  and 
Transition  Edge  Sensor  (TES)  with  each  type  has  positive 
and  negative  attributes.  The  reference  architecture  in¬ 
cludes  a  general  detector,  but  the  simulation  goals  deter¬ 
mine  the  correct  type. 

5  Conclusions  and  Future  Work 

In  this  paper,  we  have  presented  a  polarization-based, 
prepare-and-measure  BB84  QKD  reference  architecture 
used  for  to  test  a  simulation  capability  for  the  efficient 
modeling  and  analysis  of  QKD  systems.  We  provided 
detailed  illustrations  of  the  modeled  architecture  and  ac¬ 
companying  design  decisions  with  detailed  discussions  of 
each  optical  component  function  and  behavior.  This  pa¬ 


per  provides  three  distinct  aspects: 

1)  Provides  an  educational  tool  for  understanding 
QKD  architectures 

2)  Provides  detailed  discussions  of  QKD  architectural 
design  decisions  and  trade-offs 

3)  Serves  as  a  reference  "baseline"  architecture  for 
conducting  security  and  performance  analysis  of 
QKD  systems 

Puture  work  includes  adding  the  components,  controllers, 
and  protocol  logic  necessary  to  model  other  QKD  tech¬ 
nologies  including  phase-based  and  entanglement-based 
protocols  and  components,  ground-to-air,  ground-to- 
space,  space-to-space  based  systems  and  the  measure¬ 
ment  and  device  independent  protocols.  Beyond  adding 
new  technologies  to  the  simulation  frames  is  work  to  ex¬ 
ercise  the  existing  models,  for  example,  conducting  per¬ 
formance  studies  on  decoy  states  and  another  on  types  of 
SPDs.  A  forthcoming  paper  will  discuss  the  results  of 
these  studies. 

6  Disclaimer 

The  views  expressed  in  this  paper  are  those  of  the  au¬ 
thors  and  do  not  reflect  the  official  policy  or  position  of 
the  United  States  Air  Porce,  the  Department  of  Defense, 
or  the  U.S.  Government. 
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Optical  Component  Appendix 


Component 

Name 


Component  Description 


Attenuator, 
Fixed  Optical 
(FOA) 


The  Fixed  Optical  Attenuator  is  a  two  port,  bidirectional  optical  component  used  to  reduce  the  strength  of  optical 
pulses  as  they  are  transmitted.  The  amplitude  of  the  output  pulse  is  calculated  using  the  input  pulse  amplitude, 
insertion  loss,  and  fixed  attenuation  of  the  optical  pulse,  as  shown  in  the  equation  below.  Note  that  the  fixed  at¬ 
tenuation  can  be  changed  to  values  in  the  range  of  0.0  and  80.0  dB.  The  modeled  behaviors  are  based  on  [1,  2,  3, 

4]. 


Amplitudeoutput  =  Amplitude ^  10' 


-(FixedAttn) 


Attenuator, 
Electrical  Var¬ 
iable 
Optical 
(EVOA) 


The  Electrical  Variable  Optical  Attenuator  is  a  two  port,  bidirectional  optical  component  used  to  attenuate  optical 
pulses  as  they  are  transmitted.  The  amplitude  of  the  output  pulse  is  calculated  using  the  input  pulse  amplitude, 
insertion  loss,  and  variable  attenuation  of  the  optical  pulse,  as  shown  in  the  equation  below.  Note  that  the  variable 
attenuation  can  be  set  to  values  in  the  range  of  0.0  and  80.0  dB.  The  modeled  behaviors  are  based  on  [5,  6,  3,  7]. 


Amplitudeoutput  =  Amplitude ^put  *  10' 


-(VariableAttn) 


Bandpass 

Filter 


The  Bandpass  Filter  is  a  two  port,  bidirectional  optical  component  used  to  transmit  only  the  desired  wavelength  of 
light,  while  other  noise  is  blocked.  The  filtering  ranges  include  Central  Wavelength  (CWL),  upper/lower  middle- 
band  Central  Frequency  (CF),  and  upper/lower  outer  CF.  When  an  optical  pulses  is  transmitted,  1  of  4  situations 
will  occur  with  regards  to  the  optical  pulse's  CWL;  CWL  is  the  same  as  the  bandpass  filter,  CWL  is  outside  the 
bandpass  filter's  CWL  and  within  the  limits  of  middleband  CF,  CWL  is  outside  the  limits  of  the  middleband  CF 
and  within  the  bandpass  filter  CF,  or  CWL  is  outside  the  limits  of  the  bandpass  filter.  The  functionality  is  shown 
in  the  equations  below,  respectively.  The  modeled  behaviors  are  based  on  [8,  9, 10, 11, 12]. 


-InsertionLoss 


10" 


_l  bandpasscwL-^inputcwL  \  MidBandLoss 
\  MidBandWidth  )  *  10 

10  V  - 2 -  / 


-InsertionLoss 


10" 


-MidBandLoss 


10“ 


/  MidBandLowcF~^inputcwL\  (OutBandLoss-MidBandLoss) 
20  \MidBandLow-OutBandLow)  *  10 


-InsertionLoss 


-OutBandLoss 


10- 


10- 


Beamsplitter 


The  Beamsplitter  is  a  three  port,  bidirectional  optical  component  used  to  split  optical  pulses  into  two  or  more 
beams.  The  High  Output  Percentage  (HOP),  Low  Output  Percentage  (LOP),  and  other  losses  are  considered  when 
calculating  the  amplitude  of  the  output  pulse,  as  shown  in  the  equation  below.  The  modeled  behaviors  are  based 
on  [13, 14, 15, 16]. 


Amplitude  J  {^^^Xoutput)  (^^youtput) 


_  I  -ExcessLoss  I  -PolarDependLosSy  |  -InsertionLoss 

■  *VL0P*J  10  10  *Jl0  10  *Jl0  10 


_  .  -ExcessLoss  I  -PolarPependLosSy  I  -InsertionLoss 

E^y_output  =  Elyjnput  *  xfWP  *  J 10  10  *  ^  10  10  *  J 10  10 


Beamsplitter, 

Polarizing 

(PBS) 


The  Polarizing  Beamsplitter  is  a  four  port,  bidirectional  optical  component  used  to  split  optical  pulses  in  order  to 
separate  orthogonal  polarizations.  This  creates  orthogonally  polarized  optical  pulses.  The  amplitude  of  the  out¬ 
put  pulse  is  calculated  using  the  amplitude  of  the  input  pulse,  extinction  power,  and  other  losses,  as  shown  in  the 
equation  below.  The  modeled  behaviors  are  based  on  [17,  9, 14, 18, 19]. 


E4. 


'ouputAmplitude 


-  J(EAx_output)  +(^4y_, 


extinctionPower 


r 


-ExcessLoss 


IQ- 


-PolariztionDependentLosseSx 


io~ 


-InsertionLoss 


IQ- 
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Detector,  Clas¬ 
sical 


The  Circulator  is  a  three  port,  bidirectional  optical  component  used  to  route  optical  pulses  to  the  adjacent  port. 
Optical  pulses  cannot  pass  into  the  Circulator  in  the  reverse  direction,  however  an  isolate  pulse  is  created  if  a 
pulse  attempts  to  pass  in  reverse  direction.  The  amplitude  of  the  isolate  pulse  is  calculated  using  the  amplitude  of 
the  input  pulse,  insertion  loss,  and  isolation  loss,  as  shown  in  the  first  equation  below.  The  amplitude  of  the  for¬ 
ward  output  pulse  is  calculated  using  just  the  amplitude  of  the  input  pulse  and  insertion  loss,  as  shown  in  the 
second  equation  below.  The  modeled  behaviors  are  based  on  [23,  24,  25]. 

I  -(InsertionLoss+lsolationLoss) 

Amplitude  rotated  =  Amplitude  To 

I  -InsertionLoss 

Amplitudeo^tj,^t  =  Amplitude, ^  10  lo 


The  Classical  Detector  is  a  one  port,  unidirectional  optical  component  used  to  detect  optical  pulses  passing  into  the 
optical  receiver  port  that  are  strong.  Once  detected,  electrical  signals  are  generated  and  transmitted  through  the 
electrical  output  port.  The  amplitude  of  the  output  electrical  signal  is  calculated  using  the  conversion  factor  and 
peak  power  of  the  input  optical  pulse,  as  shown  in  the  equation  below.  Note  that  optical  pulses  can  only  pass  into 
the  Classical  Detector  in  the  forward  direction,  not  the  reverse  direction.  The  modeled  behaviors  are  based  on 
[20]. 


AmplitudeoutputEiectricaisignai  =  ConverslouFactor  *  PeakPower,„,,„tp„i,^ 


The  Single  Photon  Detector  is  a  one  port,  unidirectional  optical  component  used  to  detect  optical  pulses  that  are 
weak.  Optical  pulses  pass  into  the  optical  receiver  port,  but  are  detected  only  during  "gated"  periods.  Once  de- 
Detector,  Sin-  tected,  electrical  signals  are  generated  and  transmitted  through  the  electrical  output  port.  Note  that  optical  pulses 
gle  Photon  can  only  pass  into  the  Single  Photon  Detector  in  the  forward  direction,  not  the  reverse  direction.  For  a  survey  of 
(SPD)  SPD  technologies,  please  see  [21,  22]. 

D  =  rjoetector  *  Vchannei ,  with  n=efficiency 


The  Half-Wave  Plate  is  a  two  port,  bidirectional  optical  component  used  to  create  a  phase  shift  that  rotates  the 
polarization  of  the  linearly  polarized  light.  The  orientation  of  the  output  pulse  is  shown  in  the  equation  below, 
where  orientation  is  a,  elipticity  is  (p,  and  the  device  offset  angle  is  y.  The  modeled  behaviors  are  based  on  [26,  27, 
28,  29,  30]. 


Half-Wave 

Plate 


OrientationQ„,ppf  =  arccos  P(j,  a,  ip) 

P{y,cc,(p)  =  —  yj2  +  2  cos(2a)  cos(4y)  -I-  2cos{(p)  *  sin{2a)  *  stn(4y) 


The  In-line  Polarizer  is  a  two  port,  bidirectional  optical  component  used  to  polarize  optical  pulses.  Light  that  has 
polarization  orthogonal  to  the  input  pulse  polarization  of  light  is  blocked  and  only  those  of  the  same  polarization 
are  transmitted.  The  amplitude  of  the  output  pulse  is  calculated  using  the  amplitude  of  the  input  pulse,  insertion 
loss,  and  various  angle  measurements,  as  shown  in  the  first  equation  below.  The  polarization  of  the  output  pulse 
is  also  given  in  the  second  equation  below.  Note  that  orientation  is  a,  ellipticity  is  (p,  and  the  device  offset  angle  is 
Y .  The  modeled  behaviors  are  based  on  [31,  32,  33] . 

J  -(InsertionLoss) 

10  To 

*  ^(cos(a)  *  cos(y))^  -I-  (sin(a)  *  sin(y))^  +  (2  »  cos(a)  *  cos(y)  *  sin(a)  *  siniy)  *  cos(<p))^ 


PolarizatioUn 


(cos(y))^  cos(y) * stn(y) 
cos(y)  *  sm(y)  (sm(y))^ 
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Isolator 

The  Isolator  is  a  two  port,  bidirectional  optical  component  used  to  transmit  optical  pulses  in  the  forward  direction 
and  highly  attenuate  optical  pulses  passing  in  the  reverse  direction,  known  as  isolate  pulses.  The  amplitude  of  the 
isolate  pulse  is  calculated  using  the  amplitude  of  fhe  input  pulse,  insertion  loss,  and  isolation  loss,  as  shown  in  the 
first  equation  below.  The  amplitude  of  the  output  pulses  is  calculated  just  using  the  amplitude  of  the  input  pulse 
and  insertion  loss,  as  shown  in  the  second  equation  below.  The  modeled  behaviors  are  based  on  [34,  35]. 

1  -(InsertionLoss+IsolationLoss) 

Amplitudei,oiated  =  Amplitude ^put  *^J^0  lo 

1  -InsertionLoss 

Amplitudeoutput  =  Amplitude, ^put  lo 

Laser 

The  Laser  is  a  one  port,  unidirectional  ophcal  component  used  to  generate  coherent  optical  pulses,  which  are  char¬ 
acterized  as  either  a  timing  pulse  or  a  random  pulse.  Timing  pulses  are  strong  coherent  pulses,  while  random 
pulses  are  weak  coherent  pulses.  Both  types  of  pulses  are  transmitted  to  the  electrical  control  port.  Note  that 
optical  pulses  cannot  pass  into  the  Laser.  The  modeled  behaviors  are  based  on  [36,  37]. 

Optical  Switch 
1x2 

The  Ophcal  Switch  1x2  is  a  three  port,  unidirechonal  optical  component  used  to  route  optical  pulses  to  the  desired 
output  port.  This  rouhng  switches  the  output  pulses  in  order  to  monitor  the  output  power  levels.  When  a  pulse  is 
transmitted  to  the  desired  output  port,  a  reflection  of  the  pulse  is  generated.  The  amplitude  of  fhe  desired  oufpuf 
pulse  is  calculated  using  the  amplitude  of  the  input  pulse  and  insertion  loss,  as  shown  in  the  first  equation  below. 
The  amplitude  of  the  isolated  pulse  is  calculated  using  the  same  variables  as  the  amplitude  of  the  desired  output 
pulse  and  also  the  isolation  loss,  as  shown  in  the  second  equahon  below.  Note  that  ophcal  pulses  can  only  pass 
into  the  Ophcal  Switch  1x2  in  the  forward  direchon,  not  the  reverse  direchon.  The  modeled  behaviors  are  based 
on  [38,  39, 40, 41, 42]. 

1  -(InsertionLoss) 

DesiredAmplitudeoutput  —  ^tnplitude,„p„,  *  ^10  w 

1  -(IsolationLoss) 

I solatedAmplitudeg„,p„,  =  Amplitude, „p„,  *  ^10  lo 

Polarization 

Controller 

The  Polarization  Controller  is  a  two  port,  unidirechonal  ophcal  component  used  to  compensate  for  the  polariza¬ 
tion  drift  in  orientahon  and  ellipticity  that  occurs  from  the  sender  to  the  receiver  by  adjusting  the  polarization. 
The  signal  orientation  of  the  output  pulse  is  calculated  based  on  whether  the  compensation  lag  effect  flag  is  on  or 
off  and  whefher  fhe  maximum  adjustment  angle  is  less  than  or  greater  than/  equal  to  the  desired  orientation  mi¬ 
nus  the  signal  orientahon  of  the  input  pulse.  Note  that  ophcal  pulses  can  only  pass  into  the  Polarization  Controller 
in  the  forward  direchon,  nof  the  reverse  direchon.  The  modeled  behaviors  are  based  on  [45, 46,  47,  48, 49,  50]. 

Corrected  Polarization  s  Reference  Polarization  (inputsignal) 

Polarization 
Maintaining 
Fiber  Channel 

The  Polarizahon  Maintaining  Fiber  Channel  is  a  two  port,  bidirechonal  ophcal  component  used  to  propagate  opti¬ 
cal  pulses  passing  into  the  primary  port  through  the  fiber.  A  small  amount  of  attenuation  is  occurred,  but  the 
polarization  state  is  maintained.  The  amplitude  of  the  output  pulse  is  calculated  using  the  amplitude  of  fhe  input 
pulse,  insertion  loss,  and  fiber  loss,  as  shown  in  the  equation  below.  The  modeled  behaviors  are  based  on  [51,  52, 
53,  54]. 

1  -  (InsertionLoss+FiberLoss) 

Amplitude  output  =  Amplitude  ,uput  *^J^0  lo 

FiberLoss  =  Loss  *  Length/1000 

Length  =  Length  +  {Length  *  TEC  *  {Tempcurrent  “  Temp,uitiai)') 

Polarization 

Modulator 

The  Polarization  Modulator  is  a  two  port,  bidirectional  optical  component  used  to  modify  the  polarizahon  of  oph- 
cal  pulses.  Qubits  are  encoded  by  modifying  the  orientation  to  the  desired  angle.  The  amplitude  of  the  output 
pulse  is  calculated  using  the  amplitude  of  the  input  pulse  and  insertion  loss,  as  shown  in  the  equahon  below.  The 
modeled  behaviors  are  based  on  [43,  44]. 

1  -  (InsertionLoss) 

Amplitudeoutput  =  Amplitude, uput  *  “ 

Wave  Division 
Multiplexer 

The  Wave  Division  Mulhplexer  (WDM)  is  a  passive,  three  port  bidirechonal  optical  component  used  to  combine 
(or  split)  different  wavelengths  of  lighf.  When  operafing  as  a  splitter,  the  WDM  has  one  input  port  and  two  output 
ports  where  two  co-propagahng  wavelengths  are  separated  onto  individuals  fibers.  When  operahng  as  a  combin- 
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er,  the  WDM  has  two  input  ports  and  one  output  port  where  two  input  wavelengths  are  joined  on  a  single  fiber. 

WDNs  have  many  configurations,  including  free-space  dichroic  mirrors  (using  collimating  elements  to  launch 
from  and  focus  onto  the  fiber  ends)  and  in-line  fiber  devices.  In  commercial  applications,  WDMs  are  frequently 
used  for  add/drop  filters  and  signal  amplificahon  (i.e.,  erbium  doped  fiber  amplifier  (EDFA)  pumping).  Although 
advanced  WDM  devices  exist  which  can  combine  many  wavelengths,  we  are  most  interested  in  the  multiplexing 
of  two  wavelengths,  namely  the  primary  telecommunication  wavelengths  1310  and  1550  nm.  The  WDM  requires 
single-mode  input  and  output  fibers.  The  modeled  behaviors  are  based  on  [56,  57,  55]. 
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Abstract — In  this  paper,  we  present  modeling  Quantum  Key 
Distribution  (QKD)  system  components  using  the  Discrete  Event 
System  Specification  (DEVS)  formalism.  The  DEVS  formalism 
assures  the  developed  component  models  are  composable  and 
exhibit  temporal  behavior  independent  of  the  simulation 
environment.  These  attributes  enable  users  to  assemble  and 
simulate  any  collection  of  compatible  components  to  represent 
complete  QKD  system  architectures.  To  illustrate  the  approach,  we 
introduce  a  prototypical  “prepare  and  measure”  QKD  system, 
decompose  one  of  its  subsystems,  and  present  the  detailed  modeling 
of  the  subsystem  using  the  DEVS  formalism.  The  developed  models 
are  provably  composable  and  exhibit  behavior  suitable  for  the 
intended  analytic  purpose,  thus  improving  the  validity  of  the 
simulation.  Einally,  we  discuss  issues  identified  during  the 
verification  of  the  conceptual  DEVS  model  and  discuss  the  impact 
of  these  findings  on  implementing  a  hybrid  QKD  simulation 
framework. 

Index  Terms — Conceptual  Modeling;  Discrete  Event 
Simulation;  Discrete  Event  System  Specification;  Modeling  and 
Simulation,  Quantum  Key  Distribution 


I.  Introduction 

RYPTOGRPAHY,  the  practice  and  study  of  techniques 
for  securing  communications  between  two  authorized 
parties  in  the  presence  of  one  or  more  unauthorized  parties,  is 
the  centerpiece  of  a  centuries  old  battle  between  code  maker 
and  code  breaker  [1].  Historically,  only  financial,  government, 
and  military  applications  used  cryptography;  but  today  much 
of  modern  society  depends  on  cryptography  to  provide 
security  services  including  confidentiality,  integrity, 
authentication,  and  non-repudiation  [2].  While  there  are  many 
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types  of  cryptography,  only  the  One-Time-Pad  (OTP) 
symmetric  key  algorithm  is  “information-theoretically  secure” 
[3],  [4].  All  other  forms  of  cryptography  are  breakable  if  the 
adversary  has  enough  cipher  text,  computational  resources, 
and  time  [5].  Despite  its  strength,  the  OTP  is  not  in  common 
use  because  of  the  large  amount  of  secret  key  material 
required  for  its  proper  use.  These  keys  require  random 
generation,  length  equal  to  the  message,  and  single  use.  These 
requirements  impose  significant  limitations  on  use  of  the  OTP 
in  most  applications  due  the  costs  involved  with  secure  key 
generation  and  distribution. 

Quantum  Key  Distribution  (QKD)  is  a  technology  that 
offers  the  means  for  two  geographically  separated  parties  to 
create  a  shared  secret  key  [6].  QKD  is  unique  in  its  ability  to 
detect  any  third-party  eavesdropping  on  the  key  exchange, 
assuring  the  secrecy  of  the  key.  This  is  possible  due  to  the 
fundamental  laws  of  quantum  mechanics  which  ensures  any 
third-party  eavesdropping  on  the  quantum  channel  introduces 
detectable  errors.  Combining  a  QKD-generated  key  with  the 
classical  OTP  realizes  an  “unconditionally  secure” 
cryptosystem. 

A.  The  Need  for  QKD  Simulation 

However,  QKD  is  a  developing  technology  and  has  not 
been  thoroughly  studied  from  a  systems -level  perspective. 
QKD  systems  contain  non-ideal  components  that  differ, 
sometimes  significantly,  from  the  ideal  components  specified 
during  the  original  conceptual  system  design.  Therefore,  there 
is  a  need  to  develop  an  efficient  integrated  modeling  and 
simulation  capability  to  understand  the  impact  non-ideal 
components  have  on  the  performance  and  security  of  different 
QKD  system  architectures. 

There  exist  few  QKD  simulations  beyond  those  that  model 
specific  hardware  or  situations.  An  example  is  the  Austrian 
Institute  of  Technology’s  AIT  QKD  Software  project  [7]  that 
attempts  to  model  an  entire  QKD  network  but  is  based  mainly 
on  their  entanglement  QKD  hardware.  An  extensive  literature 
search  over  several  years  revealed  no  other  system-level  QKD 
modeling  &  simulation  (M&S)  efforts. 

To  address  this  shortcoming,  we  have  developed  a  modular 
simulation  framework,  named  qkdX,  which  provides  users  the 
capability  to  model  rapidly,  simulate,  and  study  QKD  system 
architectures.  This  simulation  capability  provides  hybrid 
functionality  as  it  abstracts  continuous-time  QKD  system 
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signals  (e.g.,  electrical  signals  and  optical  pulses)  into  a 
representation  suitable  as  events  in  a  Discrete  Event 
Simulation  (DES)  environment  [8].  A  continuous -time 
simulation  of  a  complete  QKD  system  is  infeasible  due  to  the 
enormous  number  of  optical  pulses  generated  during  system 
operation  and  necessitates  the  use  of  DES. 

The  researchers,  in  consultation  with  Subject  Matter 
Experts  (SMEs)  in  the  optical  physics  and  electrical 
engineering  domains,  determined  the  abstraction  necessary  for 
each  signal  model.  The  abstraction  enables  a  system-level 
simulation  where  signals  propagate  through  the  system  as 
discrete  events,  but  can  be  reconstructed  into  a  continuous¬ 
time  representation  when  mathematical  operations  or 
transformations  of  the  signals  are  required.  The  details  of  the 
optical  pulse  model  and  related  mathematical  transforms  are 
outside  the  scope  of  this  paper.  Instead,  we  focus  on  the  proper 
modeling  of  the  temporal  behavior  and  internal  “state”  of 
QKD  system  components. 

To  capture  this  temporal  behavior  and  the  state  of 
components,  we  use  the  Discrete  Event  System  Specification 
(DEVS).  In  the  past,  DEVS  has  been  used  to  model  high-level 
architectures,  hybrid-systems,  cell-spaces,  distributed  supply 
chains,  test  &  evaluation,  forest  fires,  environmental  systems, 
building  performance  models,  and  other  problem  spaces  [9- 
16].  This  paper  presents,  to  our  knowledge,  the  first  use  of 
DEVS  to  model  optical  components. 

B.  The  Need  for  Validity  in  Simulation 

Model  validity  is  a  necessary  condition  for  the  credibility  of 
simulation  results  [17].  Model  validation,  according  to  Balci, 
is  “substantiating  that  the  simulation  model,  within  its  domain 
of  applicability,  behaves  with  satisfactory  accuracy  consistent 
with  the  study  objectives”  [18].  Model  validation  is  the 
comparison  of  model  behavior  to  the  behavior  of  the  system 
under  study  when  both  are  responding  to  identical  input 
conditions  [19].  Model  testing  identifies  failures,  corrects 
them,  and  then  retests  to  the  required  accuracy  and  behavior 
[17],  [18]. 

Complete  testing  of  a  model  throughout  its  solution  space  is 
not  possible.  Such  testing  is  cost  and  time  prohibitive;  instead 
testing  continues  until  attaining  sufficient  confidence  in  the 
model  for  its  intended  purpose  [19].  Eig.  1  shows  the 
relationship  between  value,  cost  and  model  confidence.  As 
user  confidence  in  the  model  increases  there  is  a 
corresponding  logarithmic  increase  in  the  value  of  the  model, 
but  the  cost  increases  exponentially.  Eventually  the  gain  in 
value  is  negligible  but  costs  continue  to  increase  steeply. 


Fig  1.  Model  Confidence  [19]. 

Validity  and  model  confidence  relate  closely.  The  better  the 
belief  the  model  accurately  represents  the  system  under  study, 
the  higher  the  validity  of  the  model.  Higher  validity  suggests  a 
higher  confidence  in  the  model  being  useful  for  its  purpose. 
Exhaustive  testing  brings  higher  confidence,  but  at  much 
greater  cost.  Our  research  is  focused  upon  exploring  a  means 
to  increase  model  validity  without  the  need  to  exhaustively 
test  the  entire  solution  space. 

Specifically,  this  research  focuses  on  how  using  the 
Discrete  Event  System  Specification  (DEVS)  formalism  and 
concept  model  validity  theory  Oincreases  the  validity  of  a 
QKD  system-level  simulation.  To  achieve  this  goal,  we 
present  modeling  QKD  system  components  using  the  DEVS 
formalism  [20].  Representing  component  behavior  using  the 
DEVS  formalism  ensures  the  developed  conceptual  models 
exhibit  composibility  and  deterministic  temporal  behavior 
independent  of  the  simulation  environment.  Additionally,  we 
identified  unforeseen  benefits  that  arise  when  using  a  strict 
modeling  formalism. 

The  remainder  of  this  paper  is  organized  as  follows.  Section 
II  reviews  the  DEVS  formalism  and  conceptual  modeling. 
Section  III  explains  the  use  of  DEVS  in  our  modeling  effort. 
We  introduce  a  prototypical  QKD  system  architecture  and 
decompose  its  “classical  pulse  generator”  (CPG)  subsystem  in 
Section  IV.  Section  V  presents  modeling  the  CPG  subsystem 
using  DEVS  atomic  and  coupled  models.  Section  VI  presents 
our  findings,  reviews  issues  identified  during  simulation  and 
verification  of  the  conceptual  model,  and  discusses  the  impact 
of  these  findings  on  implementing  the  hybrid  simulation 
framework.  Einally,  we  provide  concluding  remarks  in  Section 
VII. 

II.  Discrete  Event  System  Specification  and 
Conceptual  Model  Validity 

A.  What  is  DEVS? 

Zeigler  first  proposed  the  DEVS  in  1976  as  a  hierarchal 
formalism  for  decomposing  complex  discrete-event  systems 
into  simple  components,  leading  to  well-defined  behavior  of 
the  overall  model  [21].  Zeigler  states  “...the  set  of  all  dynamic 
systems  is  taken  as  a  well-defined  class  in  which  each  system 
has  a  set  of  input  time  segments,  states,  state  transitions  and 
output  time  segments.”  DEVS  interprets  the  dynamic  systems 
as  sets  and  functions  and  sets  conditions  needed  for  a  well- 
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defined  specification  [22].  DEVS  defines  system  behavior, 
syntax,  and  structure,  enabling  modularity  within  a  DES  by 
building  complex  systems  from  simple  {atomic)  components. 

It  uses  dynamical  systems  theory  as  a  means  to  canonically 
represent  system  behavior  and  provide  provable  closure  under 
coupling  (also  known  as  composability)  [23],  [24].  DEVS 
provides  an  efficient  way  to  represent  complex  systems  in  a 
hierarchal  manner  to  create  coupled  (compound)  modules,  or 
subsystems,  to  create  complete  system  models.  The  theory 
states  “...the  dynamic  system  specified  by  a  coupled  model 
can  be  represented  as  (more  technically,  is  behaviorally 
equivalent  to)  an  atomic  DEVS  system”  [22]. 

DEVS  separates  the  model  from  the  source  system  and  the 
simulator.  This  allows  for  a  conceptual  model  not  tied  to  any 
particular  simulator  and  creates  a  bounded  source  with  finite 
inputs  and  outputs.  Hoffman  describes  DEVS  as  a  “theoretical 
confirmation”  of  transformations  between  different  techniques 
(&  tools  for  modeling  systems  [25]. 

Eig.  2  shows  a  representation  of  basic  entities  in  modeling 
and  simulation.  The  source  system  (i.e.,  the  system  under 
study)  couples  with  a  database  of  behaviors  derived  from  a  set 
of  inputs.  This  experimental  frame  defines  the  system  of 
interest  the  modeler  is  trying  to  capture  [26]  and  allows  the 
modeler  to  create  a  conceptual  model  for  the  system  under 
study.  Zeigler  links  the  experimental  frame  and  the  model 
with  a  modeling  relation  and  the  model  and  the  simulation 
with  a  corresponding  simulation  relation.  The  first  relation 
describes  how  well  observed  system  behavior  matches  model¬ 
generated  behavior  (validity)  and  the  second  with  how  well 
the  simulation  executes  model  instructions  (verification).  Note 
the  model  is  the  bridge  between  the  system  and  the  simulator. 


Experimental  Frame 


Fig  2.  Basic  entities  in  modeling  and  simulation,  adapted  from  [26]. 


DEVS  provides  a  concise  way  of  describing  the  inputs,  states, 
outputs,  and  timing  of  a  system  under  study.  It  is  a  formal 
language  used  to  define  the  conceptual  model  of  the  system 
[27]. 

A  DEVS  atomic  model  has  sets  of  inputs,  states,  and 
outputs  along  with  transition  and  output  functions  to  construct 
a  representation  of  any  dynamic  system  [22].  Eig.  3  provides 
a  graphic  representation  of  DEVS  modeling  state  transitions  in 
response  to  incoming  events.  We  start  in  an  initial  state  s  and 
remain  in  that  state  for  some  time  advance  period  ta.  Once  ta 
is  reached,  the  system  may  output  some  value  y  per  the  output 


function  /l(s).  Immediately  after  the  output,  the  system  goes 
through  the  internal  transition,  Si„,  (s),  based  on  the  current 
state.  The  system  changes  to  state,  s',  which  becomes  the  new 
state  s  and  the  cycle  starts  over.  If  the  state  receives  an 
external  disturbance  during  the  time  ta,  at  some  elapsed  time 
since  the  last  transition,  e,  the  system  undergoes  an  external 
transition  (5^^.,  {s,e,x).  The  external  transition  uses  the  existing 
state,  s,  the  time  elapsed  e  and  the  input  values  x  to  determine 
the  new  state,  s,  and  the  cycle  starts  anew. 


Fig  3.  DEVS  sequence  diagram,  derived  from  [28]. 


While  there  are  different  types  of  DEVS,  Parallel-DEVS 
has  several  characteristics  necessary  to  model  QKD 
components.  The  Parallel-DEVS  formalism  specifies  the 
following  about  each  atomic  model  [29]: 

•  Ports  between  models  are  represented  explicitly  -  there 
can  be  any  number  of  input  and  output  ports. 

•  Atomic  DEVS  models  can  handle  bags  of  inputs  and 
outputs. 

•  A  bag  can  contain  many  elements  with  possibly  multiple 
occurrences  of  its  elements. 

•  The  external  transition  function  handles  inputs  of  bags. 

•  The  output  function  can  generate  a  bag  of  outputs. 

•  The  confluent  transition  function,  Sconis,  ta{s),  x)  decides 
the  processing  order  of  simultaneous  external  and  internal 
events. 

In  this  paper,  we  make  use  of  Parallel-DEVS  as  it  provides 
the  unique  abilities  of  queues,  necessary  to  handle  multiple 
arriving  optical  packets,  and  the  confluence  transition 
function,  necessary  for  handling  simultaneous  events  [30]. 

B.  Why  Use  DEVS? 

The  DEVS  formalism  ensures  well-defined  component 
temporal  behavior  and  provable  closure  under  coupling  (i.e., 
composability),  allowing  for  easier  verification  of  correctness 
of  component  compositions,  and  improving  the  validity  of 
system  representations.  Thus,  for  our  purpose,  we  are  ensured 
the  temporal  behavior  of  high-level  QKD  system 
representations  reflects  the  dynamics  of  its  constituent 
parts.  In  other  words,  the  burden  of  verifying  high-level 
system  dynamics  focuses  on  correct  modeling  of  constituent 
parts  (components);  once  accomplished,  we  can  assemble 
high-level  representations  for  study  with  confidence  the 
assembly  process  itself  has  not  introduced  unforeseen  effects 
or  anomalies. 
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1 )  Conceptual  Modeling  &  Validity 

This  research  focuses  on  the  use  of  DEVS  conceptual 
modeling  to  capture  the  behavior  of  components  found  in  the 
optical  path  of  a  QKD  system.  The  question  remains  as  why 
do  this?  Conceptual  modeling  is  the  process  of  determining 
what  to  model  to  be  useful  [31].  This  process  has  been 
described  as  conceptualization  of  real-world  referents  that 
varies  from  modeler  to  modeler  [25]  whereas  Robinson 
describes  the  conceptual  model  as  “non-software  specific 
description  of  the  simulation  model  that  is  to  be  developed” 

[32] .  Deciding  the  appropriate  “wrongness”  (abstraction), 
agreement  on  the  model,  and  model  validation  are  some  of  the 
objectives  of  conceptual  modeling  [31].  Though  conceptual 
modeling  has  been  described  by  some  as  more  art  than  science 

[33] ,  Robinson  provides  a  framework  for  conceptual  modeling 
and  lists  five  activities  in  a  process  for  conceptual  modeling 
[32]: 

•  Understanding  the  problem  situation. 

•  Determining  the  modeling  and  general  project  objectives. 

•  Identifying  the  model  outputs  (responses). 

•  Identify  the  model  inputs  (experimental  factors). 

•  Determining  the  model  content  (scope  and  level  of  detail), 
identifying  any  assumptions  and  simplifications. 

This  is  where  the  usefulness  of  the  DEVS  formalism 
becomes  apparent.  It  provides  a  mathematically-proven 
process  to  work  through  the  objectives.  Using  DEVS  to  model 
the  components  for  the  QKD  demonstration  architecture  gives 
a  way  to  meet  the  objectives  of  conceptual  modeling  while 
accomplishing  the  steps  in  the  modeling  process.  DEVS  forces 
the  modeler  to  have  a  deep  understanding  of  behavior  and 
timing  which  in  turn  requires  understanding  the  problem,  the 
modeling  objectives,  and  capturing  inputs  and  outputs. 

How  hard  it  is  to  distinguish  between  the  model  and  the 
source  system  is  the  question  of  validity  [34].  The  harder  it  is 
to  distinguish  between  the  model  and  the  source  system  in  the 
experimental  frame,  the  greater  the  validity.  Note  that  a 
model’s  validity  only  applies  to  the  experimental  frame  of 
interest.  Change  the  frame  and  you  change  the  validity  of  the 
corresponding  model. 

As  mentioned,  it  is  cost-prohibitive  to  check  every  possible 
model  combination  and  trying  to  validate  the  entire  model 
space  by  model  checking  or  theorem-proving  approaches  is 
nearly  impossible  once  a  model  has  many  connections  or 
interactions  [35].  DEVS  allows  for  increased  model  validity 
without  having  to  check  the  entire  model  space. 

2)  How  Does  DEVS  Increase  Validity? 

Since  validity  is  a  measure  of  “closeness,”  how  does  DEVS 
increase  validity?  Using  DEVS  forces  the  modeler  to  have  a 
deep  understanding  of  the  modeled  behavior  because  the 
formalism  requires  it.  This  lessens  or  eliminates  undesired, 
unexpected  or  emergent  behavior.  By  knowing  exactly  how 
the  model  behaves,  it  can  be  matched  and  changed  to  the 
observed  behavior  of  the  source  system. 

DEVS  provides  three  levels  of  validity  for  conceptual 
models:  replicative,  predictive  and  structural  [34].  Each  level 


of  validity  meets  the  requirements  of  the  previous  level(s). 
The  model  and  system  achieve  replicative  validity  if  their 
behaviors  agree  to  acceptable  levels  for  all  experiments 
captured  in  the  behavioral  database  for  the  experimental 
frame.  The  second,  predictive,  requires  the  model  generate  the 
same  output  as  the  system  for  any  experiment  not  captured  in 
the  experimental  frame  database.  This  requires  the  model  to  be 
able  to  be  set  into  the  same  state  as  the  system  for  the 
experiment,  for  any  acceptable  starting  state.  Einally, 
structural  validity  requires  the  model  and  system  have  a 
corresponding  step-by-step,  component-by-component 
transition  through  all  possible  states.  Any  model  properly 
using  DEVS  achieves  all  three  of  these  states,  making  it  harder 
to  distinguish  between  the  model  and  system  under  study,  and 
increasing  its  validity,  per  the  earlier  definition. 

Another  consideration  is  the  temporal  behavior  of  the 
source  system.  In  many  discrete-event  simulators,  the 
underlying  implementation  of  the  simulator  influences  the 
behavior  of  the  model  when  multiple  simultaneous  events 
occur.  DEVS  addresses  this  problem  by  providing  a 
confluence  function  to  express  the  behavior  of  the  model  for 
these  situations.  This  means  a  DEVS  model  exhibits  the  same 
behavior  on  any  DEVS -compliant  simulator  and  if  the 
simulation  relation  is  sound,  the  behavior  can  be  replicated  on 
any  DES. 

Lastly,  DEVS  promotes  sound  model  development  when 
used  as  an  intermediate  step  towards  developing  a  large  DES 
model  using  a  non-DEVS-compliant  simulator.  Eor  example, 
some  discrete-event  simulators  schedule  events  in  the  future 
for  convenience  [36].  This  situation  can  cause  problems; 
DEVS  avoids  this  as  there  are  no  future  events  in  the 
formalism.  There  are  only  two  types  of  time  in  DEVS:  the 
time  advance  (fa)  and  the  elapsed  time  (e).  This  forces  the 
modeler  to  carefully  consider  time  and  input  interaction  on  all 
states. 

III.  Using  DEVS  to  Model  QKD  System  Components 

A.  Methodology 
1 )  The  Modeling  Process 

The  QKD  modeling  process  began  with  discussions 
between  the  research  team  and  the  SMEs  in  the  areas  of 
optical  physics,  quantum  physics,  electrical  and  software 
engineering.  These  discussions  led  to  an  agreement  on 
simulation  objectives,  what  needs  modeling,  the  fidelity 
necessary,  assumptions,  and  simplifications  needed  or  wanted 
within  the  model.  The  results  were  a  small-scale  proof-of- 
concept  simulation  using  the  OMNeT-n-  DES  [36]  to  show  the 
basic  premises  were  sound  and  selecting  DEVS  to  build  the 
conceptual  model  [8]. 

The  optical  physics  SME  created  a  mathematical  model  for 
each  of  the  optical  components  that  captured  parameters  and 
behavior  believed  necessary  for  the  model.  Model  creation 
used  a  combination  of  data  measured  during  laboratory 
experiments  in  conjunction  with  component  data  sheets  and 
existing  reference  literature.  Creating  and  verifying  the 
correctness  of  the  developed  math  models  used  Mathematica, 
a  well-known  math  computation  software  package  [37]. 
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The  next  step  was  to  transform  the  mathematical  model  into 
a  DEVS  pseudocode  model.  The  modeler  reviewed  the  math 
models  to  understand  the  necessary  transformation  functions, 
reviewed  quantum  and  optical  physics  literature  and  consulted 
with  the  SMEs  to  understand  the  required  component 
behavior.  Product  literature  for  existing  physical  components 
provided  additional  information  for  acceptable  component 
input  and  output  ranges.  The  DEVS  models  captured  this 
information  using  phases,  states  and  transitions  and  submitted 
the  component  models  back  to  the  optical  SME  for  review. 

Once  complete,  the  DEVS  pseudocode  became  the  basis  for 
creating  the  model  in  a  DEVS -compliant  simulator,  MS4ME 
[38].  MS4ME  is  a  product  of  RTSync  (www.rtsync.com),  a 
spin-off  from  the  Arizona  Center  of  Integrative  Modeling  and 
Simulation  (ACIMS)  [39].  MS4ME  provides  a  structured  user 
interface  for  modeling  in  the  ACIMS  DEVS-JAVA  language. 
Eor  each  component,  the  output  from  the  MS4ME  simulator 
was  compared  against  the  expected  behavior  of  the  DEVS 
model.  This  modeling  was  a  check  on  the  DEVS  pseudocode 
and  ensured  the  models  met  the  requirements  of  the  formalism 
and  captured  the  appropriate  behavior.  Once  checked,  the 
DEVS  pseudocode  became  the  basis  for  the  simulation 
modelers  to  create  the  qkdX  framework.  As  shown  in  Eig.  4, 
DEVS  is  the  intermediate  step  between  the  SME  mathematical 
model  and  the  QKD  simulation. 


SME 

Level 


Optical  SME 

Conceptual 

Modeling 

DEVS  research 


Simulation 

Coding 

Software  coders 


M^th 

Modfl 


(  0CV5 

I  JAVA 

\  IMS4MEI 


MAth 

Model 


QKD 

Sim 


Fig  4.  Levels  of  modeling  and  simulation. 


2 )  SME  to  Conceptual  Model  to  Simulation  Cycle 

During  the  conceptual  modeling  process,  the  modeler 
worked  with  the  software  and  electrical  engineers  to  capture 
the  hardware  and  software  behavior  of  QKD  devices.  A 
constant  review  process  looked  for  differences  between  the 
proof-of-concept  demonstrator  and  the  detailed  DEVS  models. 
Once  complete,  the  DEVS  models  went  to  the  simulation 
modelers  (the  software  and  electrical  engineers)  for  use  in 
adapting  the  existing  proof-of-concept  simulation  code  to 
agree  with  the  conceptual  model.  This  process  is  an  example 
of  the  simulation  relation. 

The  research  team  held  weekly  teleconferences  and  had 
several  site  visits  in  a  continuing  effort  to  better  understand 
and  model  the  QKD  system.  Development  of  the  DEVS 
modules  and  translation  into  the  both  the  MS4ME  DEVS 


simulator  and  the  qkdX  simulation  framework  resulted  in  the 
identification  of  multiple  inconsistencies  between  the 
representations.  These  inconsistencies  were  reconciled  to  yield 
canonical  behavior  between  all  simulation  models. 

Throughout  this  process,  the  modeler  continued  to  consult 
with  optical  SMEs.  Each  completed  model  underwent  review 
by  optical  SMEs  to  ensure  the  DEVS  model  captured  the 
proper  behavior  and  essential  parameters.  This  is  an  example 
of  the  idea  of  the  model  relation. 

Eig.  5  shows  an  overview  of  our  research  modeling  process. 
The  SME  generated  the  mathematical  models  used  to  create 
the  conceptual  models.  Constant  two-way  communication 
involved  the  SME  and  the  simulation  modelers  in  the 
conceptual  modeling  process.  Once  acceptable  to  the  SME, 
the  conceptual  models  were  given  to  the  simulation  modelers 
for  translation  into  the  simulation  framework.  Once  again, 
there  was  constant  communication  between  the  conceptual 
modeler,  the  SME  and  the  framework  modelers.  This  circular 
modeling  process  ensured  acceptance  between  all  parties. 


Fig  5.  Research  modeling  process. 

IV.  A  Prototypical  Polarization-Based  BB84  Prepare 
AND  Measure  QKD  System 

Consider  the  model  of  a  prototypical  QKD  system  that  uses 
a  polarization-based,  Bennett  and  Brassard  “BB84”  prepare 
and  measure  protocol  shown  in  Pig.  6  [40].  The  QKD  system 
comprises  an  “Alice”  subsystem,  a  “Bob”  subsystem,  an 
authenticated  public  communications  channel,  and  a  quantum 
communication  channel.  Due  to  the  complexity  of  a  QKD 
system,  we  focus  our  discussion  on  decomposition  of  the 
Alice  subsystem,  the  Alice  quantum  module  CPG  subsystem 
to  illustrate  modeling  QKD  system  components  using  DEVS. 

The  Alice  subsystem  responsibilities  include  producing  and 
encoding  photons  with  candidate  secret  key  bits  and  sending 
the  photons  to  the  Bob  subsystem  via  the  quantum  channel. 
The  Bob  subsystem  receives  the  encoded  photons  and  decodes 
them  to  recover  the  candidate  key  bits.  Alice  and  Bob 
coordinate  their  system  operations  by  communicating  over  the 
authenticated  public  channel. 
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Fig  6.  QKD  context  diagram  showing  the  QKD  system  and  the  bulk 
encryptors  using  the  generated  key. 

A.  Alice  Subsystem  Decomposition 

The  Alice  subsystem  contains  several  subsystems  including 
a  system  controller  module,  a  public  channel  module,  a 
dedicated  QKD  module,  a  quantum  module,  a  clock,  and  a 
True  Random  Number  Generator  (TRNG)  as  shown  in  Fig.  7. 


Fig  7.  Alice  subsystem  decomposition. 


The  Alice  system  controller  module  is  responsible  for 
controlling  the  Alice  subsystem  and  serves  as  the  master 
controller  to  coordinate  operations  between  Alice  and  Bob. 
The  public  channel  module  interfaces  with  the  system 
controller  module  and  provides  connectivity  to  the  remote 


system  via  the  public  channel.  The  dedicated  QKD  module 
controls  QKD-specific  processing  such  as  error  detection  and 
correction,  sifting,  and  privacy  amplification.  The  quantum 
module  is  responsible  for  generating  the  quantum  state  in 
optical  pulses  before  sending  them  to  Bob  via  the  quantum 
channel.  The  clock  source  provides  reference  timing  for  all 
synchronous  devices.  Since  the  security  of  a  QKD  system  is  a 
strong  function  of  the  randomness  of  the  numbers  it  generates, 
a  TRNG  such  as  the  idQuantique  Quantis  optical  random 
number  generator  is  typically  used  to  provide  the  required 
source  of  entropy  [41]. 

B.  Alice  Quantum  Module  Subsystem  Decomposition 

The  quantum  module  decomposes  into  nine  different 
subsystems.  Table  I  shows  a  brief  description  of  each 
subsystem  function  and  Fig.  8  illustrates  the  decomposition. 

TABLE  I 


Description  Of  Alice  Quantum  Module  Subsystems 


Subsystem 

Function 

Classical  Pulse  Generator  (CPG) 

Generates  a  multi-photon  pulse 

Polarization  Modulator 

Polarizes  the  photon  pulse  into  the 
desired  polarization 

Electronically  Variable  Optical 
Attenuator  (EVOA) 

Creates  decoy  states  to  mitigate 
photon  splitting  attacks 

Fixed  Attenuator 

Converts  classical  laser  pulses  to 
quantum  levels  by  attenuating  to 
weak-coherent  levels 

Optical  Security  Layer 

Detects  optical  probing  attacks 

Wave  Division  Multiplexer 
(WDM) 

Multiplexes  signal  and  timing 
pulses 

Timing  Pulse  Generator 

Generates  a  timing  pulse  used  for 
synchronization 

Switch 

Allows  generated  pulses  to  be 
directed  to  the  Output  Power 
Monitor  for  loop-back  testing 

Output  Power  Monitor 

Monitors  the  output  optical  power 

^ - 

System 

Controller 

Interface 


Fig  8.  Alice  quantum  module  subsystem  decomposition  showing  internal  subsystems  and  components. 


C.  Alice  Classical  Pulse  Generator  Subsystem 
Decomposition 

The  ideal  conceptual  model  of  a  QKD  system  specifies 
polarization-encoded  single  photons  with  the  desired  bit 
and  basis.  In  reality,  reliable  on-demand  single  photon  pulse 
generators  are  an  unrealized  technology.  Real-world  QKD 
system  implementations  instead  generate  a  laser  pulse 


containing  millions  of  photons  and  strongly  attenuate  the 
pulse  down  to  statistical  sub-photon  (quantum)  levels. 
Within  the  Alice  quantum  module,  the  CFG  subsystem 
generates  the  laser  pulses  and  shifts  them  into  a  known 
polarization.  The  CPG  subsystem  contains  the  components 
shown  in  Fig.  9. 
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The  CPG  subsystem  contains  a  controller,  a  laser,  an 
isolator,  an  optical  polarizer,  an  optical  bandpass  filter,  a 
beamsplitter,  a  classical  detector,  electrical  interfaces,  and 
interconnecting  polarization-maintaining  (PM)  optical  fiber. 
We  first  discuss  the  behavior  of  the  subsystem  as  a  whole 
and  then  briefly  discuss  the  behavior  of  each  of  the 
components  contained  within  the  CPG. 

D.  Individual  CPG  Component  Behavior 

1 )  CPG  Controller 

The  controller  is  an  electrical  device  containing  digital 
and  analog  circuits  responsible  for  controlling  the  laser  and 
monitoring  the  classical  detector.  It  has  a  bidirectional 
electrical  interface  to  the  quantum  module  controller,  an 
electrical  output  to  the  laser,  and  an  electrical  input  from 
the  classical  detector.  It  receives  commands  from  the 
quantum  model  controller,  sends  fire  commands  to  the 
laser,  and  monitors  the  health  of  the  laser. 

2)  Laser 

The  laser  is  an  electro-optical  device  which  contains  an 
optical  oscillator  and  emits  coherent  light.  It  has  an 
electrical  input  to  receive  control  messages  and  an  optical 
output  to  emit  generated  pulses.  Within  the  simulation,  the 
laser  creates  optical  pulses  when  it  receives  a  “fire” 
command  from  the  controller.  The  laser  generates  short- 
duration  laser  pulses  (e.g.,  ImW  peak  intensity  with  a 
500ps  duration)  containing  millions  of  photons.  The  output 
of  the  laser  couples  to  the  input  of  the  isolator  via  PM  fiber. 

3 )  Isolator 

The  isolator  is  an  optical  device  with  two  bidirectional 
optical  ports  that  passes  light  in  the  forward  direction  while 
significantly  attenuating  light  moving  in  the  opposite 
direction.  Optical  signals  arriving  at  one  port  propagate  to 
the  other  port  after  a  defined  propagation  delay  with  the 
attenuation  based  on  the  propagation  direction.  The  isolator 
assures  that  virtually  no  light  (e.g.,  reflections  or  light  from 
external  sources)  enters  the  laser.  The  output  of  the  isolator 
is  coupled  to  the  input  of  the  polarizer  via  PM  fiber 

4)  Polarizer 

The  polarizer  is  an  optical  device  with  two  bidirectional 
optical  ports  allowing  light  of  one  polarization  to  pass  while 
highly  attenuating  light  orthogonal  to  the  passed  light. 
Optical  signals  arriving  at  one  port  propagate  to  the  other 
port  after  a  defined  propagation  delay  and  polarized 
depending  on  the  polarizer  orientation  with  respect  to  the 


connected  fiber.  The  output  of  the  polarizer  is  coupled  to 
the  input  of  the  optical  bandpass  filter  via  PM  fiber. 

5 )  Bandpass  Filter 

The  bandpass  filter  is  an  optical  device  with  two 
bidirectional  optical  ports  that  passes  the  optical  energy  in  a 
narrow  band  around  the  signal  wavelength,  ks,  but  strongly 
attenuates  other  wavelengths.  This  ensures  that  only  the 
appropriate  signal  wavelength  leaves  the  subsystem  while 
preventing  other  sources  of  light  from  entering  the  laser. 
Optical  signals  arriving  at  one  port  propagate  to  the  other 
port  after  a  defined  propagation  delay  and  are  attenuated 
based  on  the  wavelength  of  the  signal.  The  bandpass  filter 
output  couples  to  port  1  of  the  beamsplitter. 

6)  Beamsplitter 

The  beamsplitter  is  an  optical  device  used  to  split  a  single 
beam  of  light  into  two  components.  It  can  also  be  used  to 
combine  two  beams  of  light  into  one  stream.  Unlike  most  of 
the  optical  devices,  it  has  four  bidirectional  optical  ports.  In 
the  splitting  configuration,  optical  signals  arriving  at  one 
port  are  split  into  two  beams,  propagating  to  the  appropriate 
output  ports  after  a  defined  propagation  delay.  Common 
splitting  ratios  are  50:50,  90:10,  and  99:1,  but  devices  exist 
in  almost  any  ratio.  Beams  can  also  be  split  according  to 
optical  wavelength  or  polarization. 

The  beamsplitter  passes  99%  of  the  pulse  through  to  port 
4,  leaving  the  CPG  and  connecting  to  the  next  quantum 
module  subsystem  as  shown  in  Fig.  9.  Meanwhile,  port  3 
passes  1%  of  the  pulse  on  to  the  classical  detector  via  PM 
fiber. 

7)  Classical  Detector 

The  classical  detector  is  an  opto-electrical  device 
containing  an  optical  photodiode  and  support  electronics  to 
generate  an  electrical  signal  proportional  to  the  power 
contained  in  the  optical  pulse.  This  signal  connects  to  the 
controller  which  stores  this  information  and  checks  to  see  if 
it  falls  below  a  predefined  threshold.  If  so,  the  controller 
notifies  the  quantum  module  controller  of  an  error 
condition. 

8)  Polarization-Maintaining  Optical  Fiber 

PM  fiber  is  an  optical  component  used  to  interconnect 
optical  devices.  It  has  two  bidirectional  optical  ports. 
Optical  signals  arriving  at  one  port  propagate  to  the  other 
port  after  a  defined  propagation  delay.  Attenuation  is  a 
function  of  the  type  and  the  length  of  the  fiber.  PM  fiber 
maintains  the  polarization  of  optical  signals  injected  along 


its  fast  and  slow  axes. 

V.  Modeling  the  Alice  Classical  Pulse  Generator 
Subsystem  using  the  DEVS  Formalism 

In  this  section,  we  discuss  features  common  to  all 
components  in  the  quantum  optical  path,  DEVS  modeling 
of  the  isolator  and  the  CPG.  We  selected  the  CPG  as  it  is 
unique  in  containing  many  types  of  components  found  in 
QKD  system  simulation:  electrical,  optical,  electro-optical, 
and  opto-electrical. 

A.  Common  Behaviors  of  Optical  Components 

All  the  components  that  interact  with  optical  signals 
share  some  common  traits.  These  include  component  state, 
losses  to  optical  intensity,  deleting  weak  packets, 
environmental  ports,  and  handling  multiple  pulses.  The 
following  section  explains  these  commonalities. 

Each  modeled  optical  component  is  in  one  of  three  states: 
normal,  degraded,  or  damaged  as  shown  in  Fig.  10.  In  the 
normal  state,  the  component  uses  a  mathematical  transform 
to  generate  the  resulting  normal  output  pulse(s)  of  the 
component  under  normal  conditions.  When  in  the  degraded 
state,  the  component  temporarily  uses  a  different  transform 
to  generate  the  resulting  degraded  output  pulse(s),  but 
returns  to  normal  after  a  predefined  time  period  or 
condition  (e.g.  when  temperature  returns  to  a  normal  level). 
When  in  the  damaged  state,  the  component  permanently 
uses  a  transform  to  generate  the  resulting  damaged  output 
pulse(s),  if  any. 


*Reflections  are  not  configured  to  be  affected  by  state 
*Electrical  signals  are  not  configured  to  be  affected  by  state 

Fig  10.  Optical  component  state  transition  diagram  showing  initialization 
and  three  states. 

Components  change  states  based  on  the  entering  optical 
packet  power  and  from  the  ambient  temperature  of  the 
component.  If  the  power  in  an  optical  pulse  exceeds  the 
defined  degraded  optical  power  threshold,  it  will 
temporarily  enter  the  degraded  state.  Similarly,  if  the  power 


in  the  optical  pulse  exceeds  the  defined  damage  optical 
power  threshold,  it  will  permanently  enter  the  damaged 
state.  The  ambient  temperature  can  also  result  in  a 
component  entering  a  degraded  or  damaged  state. 

When  an  optical  signal  arrives  at  an  optical  component,  a 
small  portion  of  the  light  reflects  opposite  to  the  light 
propagation  direction.  The  return  loss  parameter  of  the 
component  determines  the  reflected  amount,  depending  on 
different  experimental  frames.  Certain  simulation  studies 
may  require  the  capability  to  accurately  represent 
reflections,  while  not  desired  in  other  studies.  Therefore,  we 
added  the  capability  to  turn  reflections  on  and  off  for  each 
component,  reducing  the  number  of  events  when  not 
needing  this  fidelity.  The  pulse  not  only  loses  intensity  to 
reflections,  a  small  amount  is  lost  when  entering  the 
component.  This  insertion  loss  parameter  may  also  be 
turned  off  and  on. 

As  the  optical  pulses  suffer  losses  propagating  through 
the  system,  they  are  deleted  when  the  optical  power  drops 
below  a  defined  minimum  threshold.  This  reduces  the 
number  of  events  and  prevents  an  infinite  number  of 
reflections  bouncing  between  two  reflecting  components. 
Since  fiber  couples  the  optical  components  together,  we 
chose  to  implement  this  function  in  the  fiber. 

When  dealing  with  a  series  of  single  pulses,  as  is  the  case 
in  the  normal  operation  of  a  QKD  system,  an  optical 
component  typically  will  have  a  single  pulse  propagating 
through  it.  However,  a  robust  simulation  framework  must 
allow  components  to  be  able  to  handle  multiple  optical 
pulses  simultaneously  arriving  and/or  propagating  through 
it.  Therefore,  optical  components  need  a  queue  to  store  the 
multiple  pulses.  The  queue  contains  port-value  pairs  and 
any  metadata  required  to  process  the  pulse.  At  a  minimum, 
the  metadata  consists  of  the  arrival  port  and  the  time 
remaining  before  the  transformed  optical  pulse  propagates 
out  of  the  component.  As  time  transpires  in  the  model,  a 
timer  ensures  the  next  transformed  pulse  processes  at  the 
appropriate  time  and,  based  on  the  current  component  state, 
the  appropriate  transform  generates  the  output  pulse. 

Finally,  each  component  has  a  separate  environmental 
port  so  the  simulation  controller  can  send  environmental 
messages  to  mimic  temperature  variations  or  physical 
perturbations  (e.g.,  vibration)  in  the  system.  The 
temperature  state  has  no  effect  on  reflections:  a  component 
will  reflect  optical  packets  regardless  of  its  current  state. 

B.  Basic  Design  of  a  DEVS  Model  for  the  Isolator 

In  this  section,  we  discuss  how  to  model  the  isolator 
component  using  the  DEVS  formalism.  The  isolator  is 
representative  of  most  simple  optical  components  and 
shares  their  basic  behaviors.  The  isolator  allows  light  to 
pass  in  the  forward  direction  while  significantly  attenuating 
light  moving  in  the  opposite  direction.  External,  internal, 
confluence,  output  and  time  advance  functions  represent  the 
device,  as  with  all  DEVS  models  [42].  These  functions 
contain  logic  governing  how  the  component  responds  to 
inputs  and  what  and  when  it  will  output.  DEVS  uses  a 
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phase  within  a  state  as  a  “marker”  to  keep  track  of  internal 
functions  within  the  state.  Fig.  11  shows  the  DEVS  phase 
transition  diagram  for  the  isolator  and  shows  the  phases 
(rectangles),  the  transition  arcs  (arrows)  and  any  notes  for 
the  component. 


State  =  {phase,  a,  store,  temperature,  overtemp,  overpower, 
interruptRespond,  queue. xi..xn> 


dint/ 

queue=0 


ta^time 
delay 

dext  ENV/ 
update  queue 
ta;  check  over 
/  temp 


Passive 

K=a 


next  OPT/  check 
overpower;  insert  (xi,ta) 


X 


dext  ENV/ 
check 
overtemp 


dext  OPT/  update 
queue  ta;  insert 
(xi,ta) 


*dint/  insert 


Respond 
A=propagation  ^ 

\  5iSf7 

queue  IsO; 
get  queue 
(min);  set  ta 


/  s 

(xi,  ta) 

Reflect 

A= reflection 

dint/  get  queue(min);  set  ta 
tastime  delay 


tas  time  delay 


*  the  internal  transition  reflect  to  reflect  only  occurs  when 
mulitple  optical  packets  arrive  at  the  same  time 


Fig  11.  Isolator  DEVS  phase  transition  diagram. 


The  isolator  phase  transition  diagram  shows  the  full  state 
description  at  the  top,  which  includes  the  current  phase 
(“Passive”,  “Reflect”,  “Respond”),  the  current  time  advance 
((t),  variables  with  names  store,  temperature,  overtemp, 
overpower,  interruptRespond  and  the  port-value  pairs  in  the 
queue.  Taken  together,  these  variables  allow  construction  of 
the  full  state  of  the  isolator. 

The  phase  transition  diagram  shows  a  Passive  phase, 
where  the  component  awaits  input.  This  phase  has  a  time 
advance  (to)  of  infinity,  meaning  it  will  never  reach  the 
point  of  having  an  output  or  internal  transition.  Once  an 
external  event  occurs,  either  an  optical  packet  or  an 
environmental  message  arriving,  the  device  responds 
through  an  external  transition.  A  self-loop  labeled  with 
“dext  ENV/check  overtemp”  (external  environmental) 
represents  received  environmental  messages.  The  device 
stores  the  new  temperature  and  checks  against  the  damaged 
or  degraded  temperature  thresholds,  setting  the  overtemp 
state  variable  to  true  if  reaching  either  threshold.  The  time 
advance  for  the  follow-on  phase  (e.g.,  returning  back  to 
Passive)  is  on  the  other  side  of  the  arc;  in  this  case  showing 
“ta=oo”  as  the  time  advance  for  the  Passive  phase  is 
infinity. 

If  an  optical  packet  arrives,  different  external  transition 
logic  executes,  this  time  checking  to  see  if  the  arriving 
optical  power  exceeds  the  degraded  or  damaged  thresholds. 
Since  DEVS  collects  all  messages  arriving  at  the  same  time 
into  a  single  message  bag  as  an  unordered  collection,  the 
external  transition  from  the  Passive  phase  iterates  through 
the  bag,  checking  for  the  overpower  conditions  and  placing 
the  events  in  the  queue,  finally  selecting  one  at  random  for 


reflection.  Each  optical  packet  enters  the  queue  as  event  xi 
with  some  time  to,  the  time  advance  the  packet  will  remain 
in  the  component.  The  only  choices  for  Passive  phase 
external  events  are  an  environmental  or  optical  message; 
the  isolator  ignores  any  other  event  that  arrives. 

The  transition  arc  between  the  Passive  and  Reflect 
phases  with  “dext  OPT/check  overpower;  insert  (xi,ta)” 
represents  the  Reflect  phase  external  optical  event  and 
shows  the  to  for  the  Reflect  phase  is  equal  to  zero.  This 
phase  has  two  external  optical  events,  once  coming  from 
the  Passive  phase  and  one  from  the  Respond  phase. 

In  DEVS,  the  output  function  k  executes  only  before  an 
internal  transition.  The  Passive  phase  does  not  have  an 
output  function,  as  the  to  for  the  phase  is  infinity,  meaning 
there  will  never  be  an  internal  transition.  The  “X  =0”  in  the 
Passive  phase  rectangle  shows  this.  The  Reflect  phase 
output  is  the  optical  packet  reflection  and  the  Respond 
phase  output  is  the  propagated  optical  packet. 

The  Reflect  phase  has  two  possible  choices  for  the 
internal  transition,  dint,  with  the  note  at  the  bottom 
specifying  the  self-loop  “dint/insert(xi,ta)”  executes  only 
when  multiple  optical  packets  arrive  at  the  same  time.  If 
more  packets  need  reflecting,  the  self-loop  internal 
transition  is  called.  The  Reflect  phase  checks  the  queue  for 
any  packet  not  yet  reflected,  selects  it  and  emits  it.  As  noted 
before,  the  time  advance  of  this  phase  is  zero,  so  this  takes 
place  in  instant  simulation  time  until  complete.  This  follows 
the  optical  SME  guidance  that  reflections  must  take  place 
before  any  other  operation. 

Once  done  with  all  reflections,  the  Reflect  phase  enters 
the  other  internal  transition,  which  removes  the  queued 
packet  with  the  shortest  time  left  in  its  time  delay  and  sends 
it  to  the  Respond  phase.  The  transition  between  Reflect  and 
Respond  phases  labeled  “dint/get  queue(min);  set  ta”  gets 
the  minimum  value  in  the  queue  and  sets  the  time  advance. 
The  time  advance  shown  on  the  other  side  of  the  transition 
arc  is  “time  delay”  indicating  a  variable  time  for  the 
selected  packet,  this  becomes  the  time  advance  for  the 
Respond  phase. 

The  Respond  phase  holds  the  packet  for  the  time  delay, 
usually  equal  to  propagation  delay  of  the  device  (the  time  it 
takes  for  the  optical  packet  to  enter  one  side  and  emit  out 
the  other).  In  this  phase,  we  see  both  internal  and  external 
transitions.  Since  the  time  advance  of  the  phase  is  not  equal 
to  zero,  it  is  susceptible  to  external  event  interruption.  As 
the  isolator  responds  to  both  environmental  and  optical 
external  events,  it  needs  transitions  for  both.  Eor  the 
environmental  external  event,  it  is  the  same  for  the  Passive 
phase:  a  check  and  return  to  the  point  of  interruption  shown 
by  “dext  ENV/update  queue  ta;  check  overtemp.”  The 
difference  here  is  the  time  spent  in  the  phase,  equal  to  e, 
subtracts  from  every  packet  in  the  queue  and  the  optical 
packet  transitioning  the  phase.  This  is  shown  by  the  “update 
queue  ta”  on  the  dext  ENV  transition  arc. 

If  an  optical  packet  arrives,  the  “dext  OPT/update  queue 
ta;  insert(xi,ta)”  transition  arc  leaves  the  Respond  phase  to 
the  Reflect  phase,  as  it  follows  the  rule  all  reflections 
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happen  before  anything  else.  Here  we  note  the  “update 
queue  ta”  happens  again  and  the  queue  stores  the  new 
packets  with  the  “insert(xi,ta)”.  The  component  performs 
the  Reflect  phase  for  the  new  packets,  then  returns  to  the 
Respond  phase. 

But  what  happened  to  the  packet  that  was  in  the  Respond 
phase?  This  is  where  we  use  the  intermptRespond  state 
variable.  This  sets  to  true  for  an  interrupted  phase  so  the 
logic  in  the  Reflect  phase  knows  to  return  to  the  Respond 
phase  without  removing  a  new  packet  from  the  queue,  with 
a  new  time  advance  equal  to  the  time  remaining  for  that 
interrupted  packet.  Back  in  the  Respond  phase,  the  packet 
remains  for  the  remainder  of  the  time  delay,  then  the  output 
function  propagates  the  packet,  as  indicated  by  the  “1= 
propagation”  notation  under  the  name  of  the  phase.  The 
internal  dint  function  has  two  choices:  if  the  queue  does  not 
equal  zero,  it  draws  the  minimum-time  packet  out  of  the 
queue  for  propagation;  if  the  queue  is  empty,  it  advances  to 
the  Passive  phase  to  await  the  next  event. 

Interrupted  packets  present  a  design  difficulty,  as  each 
component  changes  a  propagating  packet  during  the  output 
function,  rather  than  during  input.  This  decision  ensures 
state  changes  from  an  environmental  or  control  event 
affects  the  propagating  packet,  but  also  allows  light 
entering  the  component  behind  the  packet  to  affect  it.  The 
change  to  one  packet  is  a  minor  effect  when  compared  to 
the  large  amount  of  packets  that  travel  through  components 
and  the  simulation,  on  the  order  of  1x10*  packets  per 
second.  This  design  decision  came  from  a  discussion 
between  the  modeler,  an  optical  physics  SME,  and  the  end 
user.  Here  we  see  the  simulation  design  process  in  action 
where  all  parties  involved  agree  to  the  model  choices. 
Getting  agreement  on  the  necessary  accuracy  of  the  model 
is  a  way  to  increase  the  validity  of  the  simulation. 

The  timescale  chosen  for  the  model  allows  for  several 
design  choices.  Using  the  picosecond  as  the  base  time 
allows  for  discrete  events  to  model  continuous -time  events, 
as  mentioned  earlier.  This  small  period  means  that 
components  only  affect  a  few  optical  packets  during  each 
time  unit  (typical  propagation  time  for  a  component  is  five 
picoseconds).  For  example,  we  chose  to  change  the 
temperature  of  a  device  instantly.  This  is  not  true  to  the  real 
system  but  the  team  decided  this  fast  temperature  change 
would  affect  relatively  few  packets  and  simplifies  the 
design  of  the  component.  Once  again,  the  users,  modelers 


and  optical  SME  accepted  and  agreed  on  this  design 
abstraction.  The  timescale  allows  for  the  assumption  that 
only  one  control  and  environmental  message  arrives  to 
these  ports  at  any  given  time,  again  simplifying  the  design. 

The  Appendix  contains  the  complete  DEVS  pseudocode 
for  the  isolator. 

C.  DEVS  Model  of  the  Classical  Pulse  Generator 

Since  discussing  the  isolator  design  in-depth,  we  can 
look  at  the  rest  of  the  CPG  components  in  comparison.  The 
isolator  design  follows  the  base  design  for  all  optical 
components  with  a  Passive  phase,  a  Reflect  phase  and  some 
form  of  a  Respond  phase.  The  isolator,  polarizer,  bandpass 
filter  and  the  beamsplitter  all  share  this  common  design. 
The  beamsplitter  differs  by  having  four  optical  ports  rather 
than  two  and  splits  an  incoming  optical  into  two 
propagating  packets. 

The  laser  and  classical  detector  differ  by  having  electric 
circuits  in  the  device.  They  have  an  electric  control  port  for 
control  messages  and  a  fourth  phase  to  update  the  control 
logic  within  the  device.  The  laser  is  unique  as  the  only 
device  to  create  optical  pulses  and  the  classical  detector 
receives  optical  pulses  and  outputs  a  control  message  to  the 
coupled  controller.  Response  to  optical  pulses  and 
environmental  messages  is  the  same  in  these  two  devices. 

The  PM  fiber  is  a  simple  device  with  Passive  and 
Respond  phases  because  of  the  design  decision  that  fiber 
does  not  create  reflections  when  receiving  optical  pulses.  It 
responds  in  the  same  manner  as  the  isolator  to 
environmental  messages  and  its  Respond  phase  works  the 
same.  The  largest  difference  is  the  fiber  deletes  optical 
pulses  if  their  power  is  below  a  specified  limit. 

The  DEVS  CPG  model  is  a  coupled  model  meaning  is  it 
comprised  of  atomic  models.  Fig.  12  shows  the  boundary  of 
the  CPG  and  the  components.  The  CPG  has  environmental 
and  control  input  and  output  ports  on  the  left  and  optical 
input  and  output  ports  on  the  right.  The  CPG  model  has  no 
functions  or  phases  like  other  DEVS  models,  but  because  of 
DEVS  composability  and  closure  properties,  it  behaves  as 
an  atomic  model.  The  inputs  from  external  CPG  ports 
connect  to  input  ports  on  internal  components  and  the 
output  from  one  or  more  internal  components  connects  to 
the  CPG  output  ports.  Internal  components  connect  through 
component  input  and  output  ports. 


Envin 


OptOutl 

-► 
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Fig  12.  Conceptual  DEVS  architecture  of  the  CPG. 
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The  optical  path  starts  with  the  laser  and  ends  with  the 
PM  fiber  linked  to  the  CPG  optical  output.  The  primary 
travel  direction  for  optical  packets  is  indicated  by  the  larger 
arrowhead  in  Fig.  12.  Each  of  the  optical  components  has  a 
bidirectional  optical  connection  shown  by  the  arrows 
between  each  component.  This  is  because  the  DEVS 
formalism  decomposes  a  bidirectional  connection  into  two 
separate  unidirectional  connections.  The  PM  fiber 
connected  to  the  beamsplitter  output  sends  the  optical 
packet  to  the  CPG  external  port  which  sends  the  packet  to 
the  next  subsystem.  Each  component  has  a  one-way 
environmental  port  shown  by  the  dotted-dashed  lines.  These 
ports  connect  to  higher  functions  that  send  temperature 
updates  to  each  component.  Einally,  there  are  connections 
from  the  CPG  external  and  internal  control  ports  to  the 
controller  and  control  port  connections  between  the 
controller  and  laser  and  classical  detector  and  controller. 

The  CPG  controller  is  a  simple  abstraction  of  the  electric 
circuits  connecting  devices  in  the  CPG  to  the  quantum 
controller.  Its  basic  functions  include  receiving  control 
messages  from  higher  functions,  passing  messages  to  the 
laser  and  responding  to  status  requests  from  higher 
functions.  It  receives  the  output  control  messages  from  the 
classical  detector  and  stores  detection  data.  It  has  DEVS 
pseudocode  and  functions  as  an  atomic  model. 

Table  II  lists  the  messages  from  the  quantum  module 
controller  to  the  CPG  controller.  Table  III  lists  the  messages 
from  the  classical  detector  to  the  controller.  Table  IV  lists 
the  messages  sent  by  the  CPG  controller  to  the  quantum 
module  controller,  and  Table  V  lists  the  messages  from  the 
controller  to  the  laser. 

TABLE  II 


Messages  Received  By  The  CPG  Controller  From  The  Quantum 
Module  Controller 


Input  Messages 

Response 

CPG_ENV 

Set  the  internal  CPG  controller  temperature 

CPG_RESET 

Resets  the  CPG  controller  and  clears 
variables 

CPG_STATUS_ 

REQUEST 

Sends  the  CPG  controller  status  and  stored 
magnitude  value 

CPG_FIRE_  LASER 

Sends  a  “Fire”  command  to  the  laser 

TABLE  III 


Messages  Received  By  The  CPG  Controller  From  The  Classical 
Detector 


Input  Messages 

Response 

CD_DETECTION 

Store  the  magnitude  of  the  detected  laser 
pulse 

TABLE  IV 


Messages  Sent  From  The  CPG  Controller  To  The  Quantum 
Controller 


Output  Messages 

Content 

CPG_ACK 

Response  to  a  Reset  message 

CPG_STATUS 

Response  to  a  Status  Request  message 

TABLE  V 


Messages  Sent  From  The  CPG  Controller  To  The  Laser 


Output  Messages 

Content 

CPG_LASER_  FIRE 

Command  to  fire  the  laser  one  time 

The  DEVS  model  of  the  CPG  does  not  have  the  external, 
internal,  output,  confluence  and  time  advance  functions  like 
an  atomic  model.  Instead,  the  formalism  specifies  a  set  of 
all  inputs,  a  set  of  all  outputs,  a  list  of  internal  model 
names,  a  list  of  the  atomic  models  that  comprise  the 
coupled  model,  a  list  of  external  input  and  output 
connections  and  a  list  of  internal  component  input  and 
output  connections.  The  Appendix  contains  the  DEVS 
pseudocode  for  the  CPG  and  its  controller. 

VI.  Discussion 

A.  Discoveries  Made  During  the  Modeling  Process 

Discoveries  made  during  the  conceptual  modeling 
process  fall  into  two  categories:  the  modeling  relation  and 
the  simulation  relation.  Recall  the  modeling  relation  is  a 
measure  of  how  close  the  model  is  to  the  source  system  and 
the  simulation  relation  is  a  measure  of  how  well  the 
simulation  executes  the  conceptual  model  instructions. 

1 )  The  Modeling  Relation  - 

The  original  DEVS  model  failed  to  consider  the  change 
in  attenuation  in  the  EVOA  happens  over  a  time  period 
determined  by  the  device  rate-of-change  and  the  difference 
between  the  new  and  old  attenuation  values.  Discussion 
with  the  optical  SME  uncovered  this  difference  and  lead  to 
changing  the  DEVS  model  to  an  accuracy  acceptable  to  the 
research  team. 

The  problem  with  the  EVOA  identified  the  same 
condition  with  the  polarization  controller.  In  this  case,  it 
highlighted  not  only  a  necessary  change  in  the  components, 
but  a  change  in  the  mathematical  models  for  these 
components,  as  the  necessary  parameters  were  not  in  the 
original  models. 

Both  of  these  rate-of-change  problems  necessitated  a 
change  to  the  MS4ME  model  that  was  not  in  line  with  pure 
DEVS  theory,  due  to  the  current  design  of  MS4ME.  After 
consultation  with  the  MS4  Systems  modeling  team, 
including  Dr.  Zeigler,  we  found  an  acceptable  fix  within 
MS4ME  for  the  rate-of-change  issue. 

The  DEVS  modeler  noticed  the  current  QKD 
demonstration  architecture  uses  only  the  polarization- 
independent  version  of  the  isolator,  but  other  architectures 
use  the  polarization-dependent  version.  The  optical  SME 
realized  the  need  to  provide  the  mathematical  model  for  the 
polarization-dependent  version  of  the  device  for  the  DEVS 
model.  The  updated  math  model  permitted  the  DEVS 
modeler  to  update  the  conceptual  model  to  apply  to  both 
forms  of  the  isolator. 

2)  The  Simulation  Relation - 

Identifying  the  change  to  the  EVOA  DEVS  model  made 
the  software  modelers  aware  that  these  components  in  the 
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proof-of-concept  simulation  had  the  same  “instantaneous 
change”  flaw.  Using  the  updated  conceptual  model  and 
input  from  the  SME  allowed  for  updates  to  the  simulation 
code  to  capture  the  proper  component  rate-of-change. 

Early  in  the  DEVS  modeling  of  pulsed  light,  we 
recognized  the  proof-of-concept  simulation  needed 
significant  changes  to  handle  continuous-wave  light.  The 
simulator  models  short-duration  pulses  using  picosecond 
scales,  but  continuous-wave  light  cannot  use  the  same 
abstraction  method,  requiring  changes  to  the  QKD 
simulator. 

In  the  DEVS  model,  changes  to  the  component  during 
each  optical  packet  propagation  time  affect  the  packet  as  it 
propagates  through  the  component.  Conversely,  the  QKD 
simulation  receives  a  packet  and  schedules  it  for  a  future 
propagation.  Since  the  component  could  change  during  the 
time  before  propagation,  the  scheduled  optical  pulse  may 
not  display  proper  behavior.  This  may  require  a  change  to 
how  the  QKD  simulator  handles  optical  packets.  This 
speaks  to  the  composability  of  DEVS  and  having  well- 
defined  behavior  in  the  models. 

B.  Did  I  Increase  the  Validity  ofqkdX? 

The  concept  of  validity  is  not  one  of  percentages  or  finite 
measurements.  As  defined  earlier  in  this  paper,  validity  is 
an  expression  of  how  difficult  it  is  to  differentiate  between 
the  model  and  source  system  outputs  for  the  given 
experimental  frame.  Sargent  suggests  that  “acceptance”  of 
the  model’s  accuracy  for  its  intended  purpose  is  the 
measure  of  conceptual  model  validity.  Eurther  he  states  that 
each  submodel  and  the  overall  models  need  evaluation  to 
determine  if  they  are  correct  for  the  purpose  of  the  model 
[19].  Two  of  the  primary  techniques  for  this  are  face 
validation  and  traces. 

Eace  evaluation  is  where  experts  in  the  problem  area 
evaluate  the  conceptual  model  to  determine  if  it  is  correct 
and  reasonable,  usually  by  examining  flowcharts  or 
graphical  models  or  a  set  of  model  equations  [19].  In  this 
research,  we  have  research  partners  who  are  experts  in 
quantum  mechanics,  QKD,  physics  and  optics  that 
constantly  review  the  optical  models  and  provide  feedback 
and  corrections  as  necessary. 

Traces  involve  tracking  entities  through  each  atomic  and 
coupled  model  determining  if  the  logic  and  behavior 
associated  with  each  is  proper  while  maintaining  necessary 
accuracy  throughout  [19].  The  MS4ME  simulator  provided 
visual  representations  of  the  components  as  they  transited 
through  the  models  and  produced  detailed  output  to  check 
the  accuracy  of  the  models  during  these  tests. 

As  the  models  developed,  the  SMEs  and  research  team 
provided  feedback  for  correction,  drawing  each  model 
closer  to  the  expected  system  behavior,  until  each  was 
deemed  “acceptable,”  as  discussed  in  Section  III.a.2.  Using 
the  definitions  of  validity  discussed  earlier,  this  effort 
provided  models  that  captured  the  required  behavior  and 
met  the  required  accuracy,  and  so  are  considered  “valid” 
with  the  understanding  this  validity  only  applies  to  the 
models  built  for  the  specific  experimental  frame.  Any 


change  to  the  experimental  frame  lessens  or  negates  the 
validity  of  the  models. 

C.  Benefits  of  Using  DEVS 

1)  Mathematically-proven  Formalism  for  Creating  a 
Conceptual  Model 

With  the  understanding  that  a  DES  is  a  finite  state 
machine  with  a  set  of  triples  of  inputs,  states,  and  outputs  to 
describe  each  state;  DEVS  captures  these  in  a  logical 
manner  and  provides  a  formal  language  to  describe  the 
conceptual  model.  DEVS  uses  set  theory  to  prove  its 
applicability  to  DES  models  [43]. 

2)  Tool-independent  Form  of  the  Model 

One  of  the  central  ideas  of  DEVS  is  the  model  is  the 
bridge  between  the  source  system  and  the  simulation.  There 
is  no  direct  connection  between  the  source  system  and 
simulation,  meaning  the  conceptual  model  created  using 
DEVS  is  applicable  to  any  simulation,  if  the  simulation  is 
capable  of  implementing  the  DEVS-specified  behavior.  A 
DEVS  conceptual  model  is  independent  of  a  specific 
simulation. 

3)  Closure  Under  Coupling  Within  the  Formalism 
DEVS  allows  the  modeler  to  build  hierarchal  systems 

from  smaller  subsystems  and  components.  This  property, 
also  called  composability,  ensures  DEVS  models  connect  in 
any  manner,  produce  expected  behavior  and  the  coupled 
models  are  behaviorally  equivalent  to  atomic  models. 
Together  with  tool-independence,  these  properties  allow  for 
using  repositories  of  models  in  a  “mix  and  match” 
environment. 

4)  Canonical  Understanding  of  the  Model  Behavior 
DEVS  forces  the  modeler  to  carefully  consider  all  facets 

of  desired  behavior  within  the  model,  including  all  inputs, 
outputs,  and  timing  segments.  This  greatly  reduces  or 
eliminates  emergent  or  unexpected  behavior.  By  delving 
into  the  source  system  and  creating  a  set  of  atomic  models 
not  further  decomposable,  the  modeler  creates  a  deep 
understanding  of  the  system  usable  in  any  modeling 
simulation. 

5)  Well-defined  Behavior  in  the  Conceptual  Model 
Having  a  canonical  understanding  enables  the  modeler 

create  a  set  of  rules  for  each  atomic  and  coupled  model, 
creating  well-defined  behaviors.  This  behavior  ensures  the 
model  never  enters  a  situation  where  it  moves  into  a  passive 
state  without  a  way  to  become  active  (unless  this  is  a 
behavior  the  modeler  desires).  DEVS  defines  the  conditions 
necessary  to  ensure  this  well-defined  behavior. 

D.  Limitations  of  Using  DEVS 

1 )  Applying  DEVS  to  Complex  Components 

Much  of  the  written  material  available  for  DEVS  in 
textbooks  and  papers  provides  only  simplistic  examples. 
Even  the  more  complex  examples  available  through 
RTSync  provided  little  guidance  to  model  the  optical 
components.  This  complexity  led  this  researcher  to  contact 
Dr.  Sarjoughian,  co-director  of  ACIMS,  for  advice  on  using 
DEVS  for  our  unique,  innovative  models.  He  provided 
suggestions  on  how  to  use  DEVS  to  model  the  timing  issues 
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at  the  picosecond  scale  and  capturing  wave  and  particle 
behavior. 

It  can  be  difficult  to  verify  the  DEVS  pseudocode  to  the 
source  system  behavior,  especially  true  when  modeling 
predicted  or  notional  systems.  Since  our  demonstration 
QKD  system  is  built  from  real  optical  components  but  in  a 
notional  architecture,  we  had  the  difficulty  of  verifying  the 
component  behavior.  Our  solution  to  this  problem  greatly 
increased  the  DEVS  work  by  necessitating  programing  the 
pseudocode  twice,  once  into  MS4ME,  and  then  into  the 
selected  qkdX  simulator. 

2)  DEVS  and  Processes  and  Information  Flows 

DES  models  are  increasing  in  complexity  and  being  used 
in  new  information-centered  fields.  DEVS  was  not  created 
for  these  types  of  problems  and  has  difficulty  expressing 
processes  and  information  flows  within  the  formalism. 
Heretofore,  the  solution  has  been  to  create  subsets  of  DEVS 
to  handle  the  specific  problem.  This  is  leading  to  a 
fragmentation  of  the  formalism  and  makes  it  hard  to 
determine  which  form  of  DEVS  is  appropriate  for  the 
modeling  problem. 

3)  Not  Visual  Without  Using  a  DEVS  Simulator 

DEVS  is  a  set  of  language  rules  to  formally  describe  a 
problem.  There  is  no  visual  component  to  DEVS  unless  the 
modeler  uses  a  DEVS -compliant  simulation  program. 
While  very  useful  for  being  tool-independent,  this  requires 
the  modeler  to  use  that  particular  simulator’s  functions, 
which  may  not  necessarily  conform  completely  to  DEVS, 
as  seen  with  the  EVOA  timing  issue  and  MS4ME. 

VII.  Conclusions 

The  intent  of  this  research  is  to  show  how  the  DEVS 
formalism  could  increase  the  validity  of  the  qkdX 
simulation  for  its  designed  purpose.  The  question  of  what  is 
sufficiently  accurate  is  the  question  of  validity,  as  noted  by 
Zeigler  and  Robinson.  When  used  properly,  DEVS 
increases  the  validity  of  simulation,  for  its  intended 
purpose.  No  simulation  is  valid  for  all  purposes,  so  it  is 
important  understand  Zeigler’ s  idea  of  the  experimental 
frame  so  to  carefully  limit  discussing  validity  to  an  intended 
purpose. 

To  test  our  hypothesis,  we  created  DEVS  models  for 
atomic  components  in  the  Alice  CPG  and  programmed 
them  into  a  DEVS -compliant  simulator  to  check  their 
correctness.  The  SMEs  and  the  research  team  reviewed  the 
results  (face  validity)  and  checked  the  output  values  against 
the  required  accuracies  as  events  moved  through  the  models 
(tracing).  After  correction,  the  atomic  models  were  used  in 
a  coupled  model,  the  CPG,  demonstrating  the  hierarchal 
properties  of  DEVS. 

Using  DEVS  allowed  the  team  to  refine  the  qkdX 
simulation,  correcting  several  errors  and  aiding  the  research 
team  in  recognizing  missing  behaviors  within  the 
simulation.  DEVS  increased  the  validity  of  qkdX  optical 
pathway  by  aiding  the  team  in  making  qkdX  simulation 
behavior  closer  to  the  source  system  behavior,  showing 
DEVS  can  be  used  to  increase  validity  by  creating  optical 


component  models  fit  for  the  purposes  of  the  simulation 
and  acceptable  to  the  community  of  developers  and  users. 

While  having  a  large  learning  curve,  DEVS  proved  to  be 
a  valuable  tool  for  our  research. 

VIII.  Disclaimer 

The  views  expressed  in  this  paper  are  those  of  the  authors 
and  do  not  reflect  the  official  policy  or  position  of  the 
United  States  Air  Eorce,  the  Department  of  Defense,  or  the 
U.S.  Government. 
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Appendix 


A.  Isolator  DEVS  Pseudocode 

PEVSlsolalor  ~  ^My  ^exly  ^inly  ^cony  ^y  t(l^ 

External  Transition  Function: 

Sextiphase,  <7,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“reflect”,  0,  store,  temperature,  overtemp,  overpower,interruptRespond,  queue. x\..xn) 
if  phase  =  “passive”  and  p  €  {“Optini”,  “Optini”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current. value. power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cwrr^«r) 
removQ_evQnt_m{current) 
queue. current  =  queue_first((jw^M^) 

reflect  =  {queue. current.p),  ca.\cRQf[ectQd{queue.current.v)) 

Tn'dTk_ref[ectQd{queue.current) 
interruptRespond  =  “N” 

(“reflect”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn) 
if  phase  =  “respond”  and  p  €  (“Optlni”,  “OptIn2”} 
update_delay(^w^M^) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current. value. power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrr^nr) 
remove_event_m(cwrr^nO 
queue. current  =  queue_need_reflected() 
reflect  =  {queue,  current.p),  ca.\cRef[QctQd{queue.current.v)) 
mark;_reflected((jM^w^.  current) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  qo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag. temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn) 
if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^w^M^) 
timeLeftRespond  =  time. delay-  e 
temperature  =  messagebag. temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

(phase,  a- e,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
otherwise; 

Internal  Transition  Function: 

Siniiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((p„v,),. . ..  (p„,v„))) 

(“reflect”,  0,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn)) 
if  phase  =  “reflect”  and  need.reflect  !=  null 
need,  reflect  =  queue_need_reflected() 
current  =  need.reflect 

reflect  =  {current.p),  ca.\cRef[ected{current.v)) 
mark_reflected(cwrr^«0 

{''rQspond'\  time. delay,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn) 
if  phase  =  “reflect”  and  need.reflect  =  null 
need,  reflect  =  queue_need_reflected() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
time. delay  =  current.time. delay 
if  InPort  =  “Optini” 

outputPulse  =  calcForward(cwrr^«r.v,  temperature,  overtemp,  peakpwr,  overpwr) 
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outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcReverse(cwrr^rtf.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
timeLeftRespond  =  propagation  delay 
else 

time. delay  =  timeLeftRespond 

(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn) 
if  phase  =  “respond”  and  size  >  0 
update_delay(^w^w^) 
size=  queue_size() 
current  =  queue_min() 
time. delay  =  current.time. delay 
if  InPort  =  “Optini” 

outputPulse  =  calcForward(cMrr^nr.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcReverse(cMrr^rtr.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

Confluence  Function: 

ta{s),  x)  =  dext{d intis),  0,  x); 

Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower)  = 

{reflect. p,  reflect. v) 
if  phase  =  “reflect” 


{outputPort,  outputPulse) 
if  phase  =  “propagate” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  =  a\ 

B.  Classical  Pulse  Generator  Controller  DEVS  Pseudocode 

BEVScPGconlroller  —  (-^M?  5,  Sexh  ^inli  tu) 

External  Transition  Function: 

dextiphase,  o,  store,  temperature,  overtemp,  overpower,  lastCDPower,  e,  ((p„v, (p„,v„)))  = 

(“respond”,  0,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “passive”  and  p  =  “Ctrllni” 
ctrlOutput  =  ctrlMsg(5'ror^) 
if  ctrlMsg. status  =  “init”  or  “get  status” 
outputPort  =  “CtrlOuti” 
if  CtrlMsg. status  =  “fire  laser” 
outputPort  =  “CtrlOut2” 

(“passive”,  0,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “passive”  and  p  =  “Ctrlln2” 
lastCDPower  =  messagebag. magnitude 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag. temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

{phase,  o-  e,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
otherwise; 
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Internal  Transition  Function: 

Si„, (phase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  = 

(“passive”,  co,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “respond” 

Confluence  Function: 

5c„„(s,  ta(s),  x)  =  5g„(di„,(s),  0,  v); 

Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  = 

(output.port,  output.pulse) 
if  phase  =  “respond” 

(outputPort,  ctrlOutpuf) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  =  (t; 

C.  Classical  Pulse  Generator  Coupled  Model  Pseudocode 

DEVScpg  =  (X,  r,  D,  {M^\A£D], EIC, EOC, IC) 

InPorts  =  {“Ctrllni”,  “Ctrlln2”,  “Optini”,  “Optins”,  “Optin/’,  “Envin”) 

X  =  {(“Ctrllni”,  v),  (“Ctrlln2”,  v),  (“Optini”,  v),  (“Optins”,  v),  (“OptIn4”,  v),  (“Envin”,  v)  Iv  E  V] 

OutPorts  =  {“CtrlOuti”,  “CtrlOut2”,  “OptOuti”,  “OptOuts”,  “OptOut/’) 

Y  =  {(“CtrlOuti”,  v),  (“CtrlOut2”,  v),  (“OptOuti”,  v),  (“OptOuts”,  v),  (“OptOut4”,  v)  Iv  E  Vj 

D  =  {controller,  laser,  isolator,  polarizer,  bandpass,  beamsplitter,  classicaldetector,  PMfiber} 

—  ^controllers  ^ ieolatorr  ^irolorizer,  lYl handpassr  ^^hearnsplitterr  ^cleessicaldelectorr  pidfther 

EIC  =  [((N,  “Ctrllni”), (controller,  “Ctrllni”)),  ((N,  “Envin”), (controller,  “Envin”)),  ((N,  “Envin”), (laser,  “Envin”)),  ((N,  “EnvIn”),(isolator,  “Envin”)),  ((N, 
“Envin”), (polarizer,  “Envin”)),  ((N,  “Envin”), (bandpass,  “Envin”)),  ((N,  “Envin”), (beamsplitter,  “Envin”)),  ((N,  “Envin”), (classicaldetector,  “Envin”)),  ((N, 
“EnvIn”),(PMfiber,  “Envin”)),  {{{N,  “OptIni”),(PMfiber,  “OptIn2”))) 

EOC  =  {((PMfiber,  “OptOut2”),(-/V,  “OptOuti”)),  ((controller,  “CtrlOuti”), (W,  “CtrlOuti”))) 

IC  =  {((controller,  “CtrlOut2”),  (laser,  “Ctrlln”)),  ((laser,  “OptOuti”), (PMfiber,  “Optini”)),  ((PMfiber,  “OptOut2”),  (isolator,  “Optini”)),  ((isolator  “OptOut2”), 
(PMfiber,  “Optini”)),  ((PMfiber,  “OptOut2”),  (polarizer,  “Optini”)),  ((polarizer  “OptOut2”),  (PMfiber,  “Optini”)),  ((PMfiber,  “OptOut2”),  (bandpass,  “Optini”)), 
((bandpass  “OptOut2”),  (PMfiber,  “Optini”)),  ((PMfiber,  “OptOut2”),  (beamsplitter,  “Optini”)),  ((beamsplitter,  “OptOut4”),(PMfiber,  “Optini”)),  ((beamsplitter, 
“OptOuts”), (PMfiber,  “OptIn2”)),  ((PMfiber,  “OptOuti”),(classicaldetector,  “Optini”)),  ((classicaldetector,  “CtrlOut”),(controller,  “Ctrlln2”)),  ((classicaldetector, 
“OptOuti”),  (PMfiber,  “Optini”)),  ((PMfiber,  “OptOut2”),  (beamsplitter,  “Optins”)),  ((PMfiber,  “OptOuti”),  (beamsplitter,  “OptIn4”)),  ((beamsplitter, 
“OptOuti”), (PMfiber,  “OptIn2”)),  ((PMfiber,  “OptOuti”),  (bandpass,  “OptIn2”)),  ((bandpass,  “OptOuti”), (PMfiber,  “OptIn2”)),  ((PMfiber,  “OptOuti”),  (polarizer, 
“OptIn2”)),  ((polarizer,  “OptOuti”), (PMfiber,  “OptIn2”)),  ((PMfiber,  “OptOuti”),  (isolator,  “OptIn2”)),  ((isolator,  “OptOuti”), (PMfiber,  “OptIn2”)),  ((PMfiber, 
“OptOuti”),  (laser,  “OptIn2”))) 


8.  Simulation  Results  and  Analysis 


The  purpose  of  this  chapter  is  to  present  the  results  of  the  research  by  discussing 
the  qkdX  QKD  simulation  framework,  the  model  creation  process,  providing  samples  of 
simulation  output  and  analyzing  the  output.  Several  data  tables  provide  summaries  for  the 
components  and  coupled  submodules. 

8.1  The  QKD  Simulation  Framework  (qkdX) 

The  AFIT  QKD  research  team  developed  a  QKD  simulation  framework  (qkdX)  to 
enable  efficient  modeling  of  QKD  systems  for  performance  analysis  and  characterization. 
Design  features  of  qkdX  include:  a  hybrid  discrete-continuous  modeling  approach  to 
more  accurately  capture  quantum  effects;  a  modular  design  to  allow  quick  and  efficient 
changes  to  the  system  under  study;  parameterized  components  allowing  for  multiple 
varying  instances;  a  compos  able  system  allowing  for  hierarchal  construction  of  complex 
systems  from  simple  components. 

This  capability  allows  users  (e.g.,  engineers  or  analysts)  to  more  quickly  model 
QKD  systems,  enabling  security  and  performance  analysis,  including: 

•  Model  and  analyze  competing  QKD  implementations  (e.g.,  variations  in  hardware 
components  or  software  processes) 

•  Increase  understanding  of  the  security-performance  design  and  implementation 
trade  space  for  realized  QKD  systems 

•  Determine  the  impact  of  non-idealities  and  practical  engineering  limitations  in 
QKD  architectures 

•  Identify  interactions  between  physical  (quantum  phenomenon,  temperature,  and 
disturbances)  and  system-level  interactions  (hardware  designs,  software 
implementations,  and  protocols) 

•  Propose  and  assess  new  QKD  implementations  or  protocols 
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•  Study  the  security  implications  of  different  protocol  modifications  and  system 
architectures 

•  Model  performance  characteristics  of  free-space  and  space-based  QKD  systems 

•  Maximize  research  development  efforts  to  improve  implementations  (e.g.,  should 
one  invest  research  capital  in  on-demand  single-photon  sources  or  improved 
single  photon  detectors?) 

The  framework  is  designed  with  considerations  to  support  multiple  qubit  encoding 
schemes  (i.e.,  polarization-based,  phase-based,  and  entanglement),  multiple  protocols 
(e.g.,  BB84,  SARG04,  E92),  and  various  QKD  applications  (e.g.,  buried  optical  fiber, 
terrestrial  directional  free-space  optical  link,  and  multiplexed  transmissions).  Initially,  the 
framework  was  used  to  model  a  notional  polarization-based,  prepare- and-measure  BB84 
terrestrial  fiber  QKD  system.  This  research  constructed  and  tested  the  conceptual  models 
for  the  optical  path  components  necessary  for  BB84  system. 


8.2  Component  Modeling 

The  process  for  creating  each  coupled  and  atomic  model  for  the  reference 
architecture  consisted  of  multiple  steps.  Appendix  B  has  a  detailed  description  of  model 
creation  and  testing  but  from  an  overview  perspective,  the  process  creating  and  testing 
the  optical  models  consisted  of: 

1 .  Optical  SME  created  a  mathematical  model  of  the  component 

2.  Use  the  mathematical  model  to  create  a  component  conceptual  model 

3.  Create  DEVS  pseudocode  to  capture  the  behavior  and  timing  aspects 

4.  Create  MS4ME  models  using  the  DEVS  pseudocode 

5.  Test  the  MS4ME  models  to  ensure  proper  behavior  and  timing 

6.  Share  results  with  optical  SME  throughout  the  steps  to  check  models 

Each  component  model  started  with  a  mathematical  model  from  the  optical  SME.  A 
description  of  the  component  based  on  the  mathematical  model,  commercial  data  sheets 
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and  academic  literature  provided  the  basic  understanding  needed  for  the  conceptual 
model.  The  conceptual  model  and  terse  uses  cases  for  the  component  lead  to  a  series  of 
English-language  rules  describing  the  high-level  behavior  of  the  component  and  these 
were  captured  graphically  in  a  phase  transition  diagram.  Event-trace  diagrams,  in  the 
form  of  state  tables,  provided  a  written  version  of  the  phase  changes  shown  in  the  phase 
transition  diagram. 

DEVS  pseudocode  captured  the  identified  component  behavior  and  timing  using 
the  preceding  diagrams,  rules  and  use  cases.  The  pseudocode  was  programmed  into  the 
DEVS-compliant  MS4ME  simulator  with  the  output  captured  for  later  evaluation.  After 
manually  checking  the  component  output  against  the  mathematical  model  and  expected 
behavior  in  the  DEVS  pseudocode,  the  MS4ME  models  were  completed  after  multiple 
iterations  of  testing  and  correction,  and  then  used  to  construct  the  coupled  submodules  in 
MS4ME. Table  2  lists  the  appendix  containing  the  related  documents  for  each  component 
and  coupled  submodule. 


Table  2.  List  of  Modeled  Components  and  Submodules. 


Appendix  # 

Component 

Appendix  # 

Component 

D 

Bandpass  Eilter 

P 

Pulse  Modulator 

E 

Beamsplitter 

Q 

Polarizing 

Beamsplitter 

E 

Circulator 

R 

SM  Eiber 

G 

Optical  Photodiode 

(Classical  Detector) 

S 

Optical  Switch 

H 

EVOA 

T 

WDM 

I 

Eixed  Attenuator 

U 

CPG  Module 

J 

Half-wave  Plate 

V 

PM  Module 

K 

In-line  Polarizer 

w 

DSG  Module 

E 

Isolator 

X 

CTQ  Module 

M 

Easer 

Y 

OSE  Module 

N 

PM  Eiber 

Z 

TPG  Module 

0 

Polarization  Controller 

AA 

0PM  Module 
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Each  optical  component  was  tested  by  sending  inputs  into  the  component, 
capturing  the  output,  and  evaluating  the  output  line-by-line  to  check  behavior  and  timing. 
Each  component  had  each  of  its  input  ports  (optical,  environmental  (env),  and/or  control 
(Ctrl))  tested  singly,  then  in  different  combinations  of  ports  and  input  messages.  To  test  an 
optical  port,  an  optical  message  is  injected  into  that  port  when  the  component  is  in 
Passive  or  Respond  phase.  This  tests  the  component  behavior  when  it  is  not  active  and 
awaiting  input  and  tests  the  behavior  when  the  component  is  interrupted  during  message 
processing.  Control  messages  work  in  the  same  way,  but  force  the  component  to  begin 
behavior  to  react  to  the  contents  of  the  messages.  Environmental  packets  force  an 
immediate  response  to  the  change  in  temperature,  possibly  changing  the  properties  of  the 
component  if  it  is  damaged  or  degraded  by  the  new  temperature.  All  identified  errors 
were  corrected  and  the  component  retested  until  it  functioned  properly  for  each  test  case. 
Once  the  component  completed  testing,  the  component  documentation  and  results  went  to 
the  optical  SME  for  review. 

Table  3  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or 
Respond  phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows 
the  number  of  tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total 
number  of  tests  performed  on  a  component;  successive  columns  list  the  number  of  those 
tests  that  exercise  a  particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or 
multi-port  tests,  with  the  final  column  listing  the  number  of  math-specific  tests.  These 
math  tests  were  created  by  the  optical  SME  to  exercise  the  early  demonstration  QKD 
simulation  and  added  in  the  MS4ME  code  for  possible  future  work  in  comparing  the 
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conceptual  models  to  the  qkdX  framework  (see  chapter  7  for  a  discussion  on  this 


framework). 


Table  3.  Summary  of  Component  Behavior  Testing. 


Passive  Phase 

Respond  Phase 

total  tests 

optical 

ports 

Ctrl 

port 

env 

port 

single 

port 

multiple 

port 

math 

tests 

total 

tests 

optical 

ports 

Ctrl 

port 

env 

port 

single 

port 

multiple 

port 

math 

tests 

Bandpass  Filter 

21 

20 

0 

13 

5 

16 

4 

21 

21 

0 

13 

4 

17 

0 

Beamsplitter 

33 

28 

0 

21 

9 

24 

6 

33 

33 

0 

21 

8 

25 

0 

Circulator 

27 

26 

0 

17 

6 

21 

6 

27 

27 

0 

17 

6 

21 

0 

Classical 

Detector 

21 

14 

14 

13 

5 

16 

7 

21 

21 

14 

13 

1 

20 

0 

EVOA 

30 

24 

13 

18 

6 

24 

7 

22 

22 

9 

11 

2 

19 

0 

Fixed 

Attenuator 

21 

20 

0 

13 

5 

16 

7 

21 

21 

0 

13 

4 

17 

0 

Half-wave 

Plate 

21 

20 

0 

13 

5 

16 

8 

21 

21 

0 

13 

4 

17 

0 

In-line 

Polarizer 

49 

20 

0 

13 

5 

16 

7 

21 

21 

0 

13 

4 

17 

0 

Isolator 

49 

20 

0 

13 

5 

16 

7 

21 

21 

0 

13 

4 

17 

0 

Laser 

21 

14 

14 

13 

5 

16 

7 

21 

21 

15 

13 

2 

19 

0 

Optical  Switch 

35 

29 

14 

19 

7 

28 

8 

27 

27 

10 

12 

2 

25 

0 

PM  Fiber 

21 

20 

0 

13 

3 

18 

7 

21 

21 

0 

13 

4 

17 

0 

Polarization 

Controller 

30 

24 

13 

18 

6 

24 

8 

22 

22 

9 

11 

2 

20 

0 

Polarization 

Modulator 

30 

24 

13 

18 

6 

24 

8 

22 

22 

9 

11 

2 

20 

0 

Polarizing 

Beamsplitter 

33 

28 

0 

21 

9 

24 

7 

33 

33 

0 

21 

8 

25 

0 

SM  Fiber 

21 

20 

0 

13 

3 

18 

7 

21 

21 

0 

13 

4 

17 

0 

Wave  Division 
Multiplexer 

27 

26 

0 

17 

4 

23 

7 

27 

27 

0 

17 

6 

21 

0 

8.3  Coupled  Submodule  Modeling 

The  process  for  creating  each  coupled  submodule  used  the  same  process  in 
creating  the  components  with  one  major  difference.  Each  coupled  model  uses  the 
prototypical  demonstration  architecture  as  a  starting  basis  (see  chapter  7),  rather  than  a 
mathematical  model.  Under  DEVS,  a  coupled  model  does  not  have  its  own  logic  or 
behavior,  but  rather  serves  as  a  repository  of  atomic  models  (see  the  DEVS  code  for  the 
coupled  models  in  each  of  the  appendices  U-AA).  Some  coupled  submodules  have  a 
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simple  controller  component  that  represents  the  logic  necessary  to  control  any  opto- 
electrical  devices  within  the  submodule.  Each  of  these  controllers  has  typical  DEVS 
atomic  behavior. 

Each  coupled  submodule  was  tested  by  sending  messages  to  the  submodule  and 
using  the  operational  graphics  of  the  MS4ME  simulator  to  track  the  progress  of  the 
message  through  the  submodule.  The  primary  purpose  of  the  test  cases  was  testing  the 
ability  of  the  coupled  submodule  to  receive  messages,  pass  them  internally  to  the 
submodule  controller  and  pass  internal  output  to  external  ports.  The  controller  processed 
these  input  messages  and  passed  an  appropriate  message  to  the  controlled  opto-electrical 
component.  The  control  message  passed  to  each  coupled  submodule  depended  on  the 
internal  components. 

1.  CPG  submodule  -  control  message  fires  signal  laser 

2.  PM  submodule  -  control  message  changes  polarization  of  polarization  controller 

3.  DSG  submodule  -  control  message  changes  attenuation  of  EVOA 

4.  CTQ  submodule  -  control  message  changes  attenuation  of  EVOA 

5.  OSE  submodule  -  no  control  message  to  change  internal  settings 

6.  TPG  submodule  -  control  message  fires  timing  laser 

7.  0PM  submodule  -  control  message  changes  optical  switch  position 

The  exceptions  for  the  test  cases  were  the  CPG  and  the  OSE.  The  CPG  did  not 
have  a  test  case  to  inject  an  optical  packet  as  the  CPG  is  the  module  that  creates  the 
optical  pulse.  The  OSE  had  one  less  control  message  as  its  “controlled”  device  is  the 
classical  detector,  which  only  sends  data  to  the  controller,  and  does  not  accept  input 
control  message 

These  test  cases  led  to  iterations  of  testing  and  correction  (see  appendix  B  for  detailed 
descriptions).  All  the  errors  identified  in  the  coupled  submodules  were  problems  with 
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coding  the  controllers,  as  the  atomic  components  functioned  properly  during  coupling. 


See  Table  4  for  a  summary  of  these  tests. 


Table  4.  Summary  of  Coupled  Submodule  Behavior  Testing. 


total 

tests 

Test  Type 

optical 

port 

Ctrl 

port 

env 

port 

Classical  Pulse  Generator 

4 

0 

3 

1 

Polarization  Modulator 

5 

1 

3 

1 

Decoy  State  Generator 

5 

1 

3 

1 

Classical  To  Quantum 

5 

1 

3 

1 

Optical  Security  Layer 

4 

1 

2 

1 

Timing  Pulse  Generator 

5 

1 

3 

1 

Optical  Power  Monitor 

5 

1 

3 

1 

8.3.1  CPG  Testing 

In  the  following  figures,  Figure  2  is  the  CPG  architecture  diagram.  Figure  3  is  the 
high-level  test  frame  and  Figure  4  shows  the  exploded  view  of  the  CPG  submodule 
within  the  high-level  test  frame.  Notice  there  is  a  “cpgcontroller”  that  receives  messages 
from  outside  the  CPG.  This  is  a  simple  representation  of  the  logic  circuits  necessary  to 
operate  this  module.  In  these  conceptual  models,  the  controller  reacts  to  the  appropriate 
message  types  for  the  opto-electrical  components  connected  to  the  controller.  For 
example,  the  CPG  controller  accepts  messages  for  the  laser  and  the  classical  detector. 
Similarly,  each  coupled  model  has  a  controller  specific  for  its  needs. 
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Figure  2.  CPG  architecture. 


Figure  2.  CPG  test  frame. 


Figure  4.  CPG  coupled  submodule  eomponents. 

The  testing  construct  for  each  coupled  module  is  the  same.  There  is  test 
eomponent  ealled  “Upstream”  that  injects  messages  into  the  submodule  under  test  and  a 
testing  eomponent  ealled  “Downstream”  that  captures  all  output  from  the  submodule. 
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Figure  3  shows  the  expframe  module  with  the  two  test  components  and  the  CPG 
submodule,  each  labeled  with  its  current  phase  and  ports.  As  noted  earlier,  Upstream  only 
has  output  ports  (labeled  with  “out”)  connected  to  the  CPG  input  ports  (labeled  with 
“in”),  and  all  of  the  CPG  output  ports  are  connected  to  Downstream’s  input  ports.  Since 
the  CPG  does  not  output  environmental  (labeled  “env”)  messages,  there  are  is  no 
environmental  input  port  in  Downstream.  Each  optical  component  and  submodule  listed 
in  Table  2  has  a  similar  testing  construct  built  in  MS4ME. 

The  code  necessary  for  building  coupled  models  much  simpler  than  the  code  for 
the  components.  The  coupled  model  code  specifies  external  components  (Upstream, 
Downstream)  and  external  inputs  and  outputs  for  the  CPG  module.  Additionally,  the  code 
lists  all  internal  components  and  the  internal  connections  between  them.  Einally,  the 
connections  from  the  CPG  to  internal  components  are  defined.  Eor  a  coupled  model, 
there  are  no  phases  or  transitions  defined,  as  the  ‘state’  of  the  coupled  model  is  the  sum 
of  all  current  states  of  all  internal  components.  Appendix  U  describes  the  CPG  in  detail 
and  each  coupled  module  appendix  (U-AA)  has  the  DEVS  code  for  the  controller  and  the 
coupled  module. 

Once  constructed,  each  coupled  model  was  tested  by  injecting  the  proper  message 
packet  into  the  submodule.  Every  coupled  model,  except  the  CPG,  has  input  optical, 
environmental  and  control  ports.  The  CPG  has  no  input  optical  port,  as  the  laser  within 
the  CPG  generates  optical  pulses  for  the  Alice  subsystem  and  its  primary  input  is  a 
control  message  to  fire  the  laser.  Table  5  summarizes  the  test  cases  for  the  CPG 
submodule. 
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Table  5.  Example  test  case  timing  chart  -  CPG. 


Inject  Ports 

Running  Totals 

Case 

Optl 

Ctrl 

Env 

Timing 

opt  # 

env  # 

Ctrl  # 

1 

0 

1 

0 

single 

0 

0 

1 

2 

0 

1 

0 

single 

0 

0 

2 

3 

0 

0 

1 

single 

0 

1 

2 

4 

0 

1 

0 

single 

0 

1 

3 

totals 

0 

3 

1 

8.3.2  CPG  MS4ME  Output 

This  section  contains  the  output  from  MS4ME  while  running  the  CPG  submodule. 
This  is  the  output  from  Test  Case  1  (highlighted  in  Table  5)  and  starts  at  simulation  time 
10.  Major  events  described  in  this  paragraph  are  highlighted  in  yellow  in  the  following 
MS4ME  output.  Case  1  starts  with  Upstream  having  an  output  event  at  time  10,  sending 
the  message  to  the  CPG  which  seamlessly  passes  the  message  inside  the  submodule  to  the 
CPG  controller.  The  controller  receives  a  EaserMsg  with  id:l  on  port  Ctrllnl  and  starts 
the  Passive  external  event.  The  controller  sees  it  has  received  a  laser  fire  message  and 
moves  to  the  Respond  phase.  The  controller  notes  that  the  status  number  of  the  message 
is  6,  the  stored  power  value  of  the  last  classical  detection  is  zero  (this  is  sent  from  the 
classical  detector  when  it  has  a  detection)  and  prepares  a  response  message  and  sends  it 
out  port  CtlrOut2,  ending  the  Response  phase. 

The  response  message  goes  to  the  laser,  which  receives  the  message  on  port  Ctrlln 
and  starts  the  Passive  Ctrlln  event.  The  laser  decodes  the  message,  moves  to  the  “ON” 
setting  and  prepares  a  fire  control  message  for  port  CtrlOut.  The  laser  moves  to  the 
Update  Easer  phase  where  it  notes  the  laserpower  variable  is  “true,”  indicating  the  laser  is 
on.  The  laser  begins  preparing  an  optical  pulse  for  output  on  OptOutl  (the  only  optical 
output  port  in  the  laser)  and  notes  it  is  moving  to  the  Create  Pulse  phase.  Once  in  the 
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Create  Pulse  phase,  the  laser  outputs  the  generated  optical  pulse  on  port  OptOutl  and 
ends  the  Create  Pulse  phase.  Finally,  the  next  component  in  line  from  the  laser,  the 
pmfiberl,  receives  the  optical  pulse  at  simulation  time  16.  This  output  shows  how  the 
CPG,  the  CPG  controller,  and  the  CPG  internal  laser  reacts  to  a  “fire  laser”  message  to 
generate  optical  pulses  at  the  beginning  of  the  optical  path  within  Alice. 


[10.0,  2:13:36.632]  SimViewer_expframe:  Simulation  step  started 

[10.0,  2:13:36.632]  Upstream  -  output  event  for  Casel  -  time  Elapsed:  NA  getTimeAdvance:  10.0  clock:  10.0 
[10.0,  2:13:36.632]  SimViewer_expframe.expframe.expframe. Upstream:  Internal  transition 
[10.0,  2:13:36.632]  SimViewer_expframe.expframe.expframe. Upstream:  Internal  transition  from  Casel 
[10.0,  2:13:36.632]  SimViewer_expframe.expframe.expframe. Upstream:  Holding  in  phase  Casel_l  for  time  1.0 
[10.0,  2:13:36.632]  Upstream  -  internal  event  for  Casel  -  time  Elapsed:  NA  getTimeAdvance:  1.0  clock:  10.0 
[10.0,  2:13:36.632]  Upstream  -  internal  event  for  Casel  -  time  Elapsed:  NA  getTimeAdvance:  10.0  clock:  10.0 
[10.0,  2:13:36.632]  SimViewer_expframe:  Simulation  step  finished 
[11.0,  2:13:36.773]  SimViewer_expframe:  Simulation  step  started 

[1 1.0,  2:13:36.788]  Upstream  -  output  event  for  Casel_l  -  time  Elapsed:  NA  getTimeAdvance:  1.0  clock:  1 1.0 

[11.0,  2:13:36.788]  SimViewer_expframe.expframe.expframe. Upstream:  Internal  transition 

[1 1.0,  2:13:36.788]  SimViewer_expframe.expframe.expframe. Upstream:  Internal  transition  from  Casel_l 

[1 1.0,  2:13:36.788]  SimViewer_expframe.expframe.expframe. Upstream:  Holding  in  phase  Waitl  for  time  49.0 

[1 1.0,  2:13:36.788]  Upstream  -  internal  event  for  Casel_l  -  time  Elapsed:  NA  getTimeAdvance:  49.0  clock:  1 1.0 

[1 1.0,  2:13:36.788]  Upstream  -  internal  event  for  Casel_l  -  time  Elapsed:  NA  getTimeAdvance:  1.0  clock:  1 1.0 

[11.0,  2:13:36.788]  SimViewer_expframe.expframe.expframe.cpg.cpgcontroller:  Received  messages  [inCtrllnl:  LaserMsg 

I  id:  l| 

name:  Case  1  Control  Message  1 
status:  6 
magnitude:  0.0] 

[11.0,  2:13:36.788]  SimViewer_expframe.expframe.expframe.cpg.cpgcontroller:  External  transition 

[1 1.0,  2:13:36.788]  SimViewer_expframe.expframe.expframe.cpg.cpgcontroller:  Holding  in  phase  Respond  for  time  0.0 

[11.0,  2:13:36.788]  CPG  CONTROLLER  -  START  PASSIVE  CTRLINl  EXTERNAL 

[1 1.0,  2:13:36.788]  CPG  Controller  -  external  event  for  Passive  Ctrlln  with  Ctrlln  -  time  Elapsed:  1 1.0  getTimeAdvance:  0.0  clock: 
11.0 

[11.0,  2:13:36.788]  CPG  Controller  received  a  laser  fire  messn]|^ 

[1 1.0,  2:13:36.788]  CPG  Controller  -  Preparing  laser  fire  control  message  for:  Case  1  Control  Message  1  to  port  CtrlOut2 
[1 1.0,  2:13:36.788]  SimViewer_expframe.expframe.expframe.cpg.cpgcontroller:  Holding  in  phase  Respond  for  time  0.0 
[11.0,  2:13:36.788]  CPG  CONTROLLER  -  END  PASSIVE  CTRLINl  EXTERNAL 

[11.0,  2:13:36.944]  SimViewer_expframe:  Simulation  step  finished 
[11.0,  2:13:37.54]  SimViewer_expframe:  Simulation  step  started 

[11.0,  2:13:37.54]  @@*************  CPG  CONTROLLER  -  START  RESPOND  OUTPHTl 

[1 1.0,  2:13:37.54]  CPG  Controller  -  output  event  for  Respond  -  time  Elapsed:  NA  getTimeAdvance:  0.0  clock:  1 1.0 

[11.0,  2:13:37.54]  sendCtrl  getStatus  =:  6 

[11.0,  2:13:37.54]  Last  Classical  Detection  Optical  Power  =:  0.0 

[1 1.0,  2:13:37.54]  ###  CPG  Controller  -  Sending  laser  fire  message:  CPG  Controller  FIRE  Response  Message  for  Case  1  Control 
Message  1  to  port  CtrlOut2 

[11.0,  2:13:37.54]  Pulses  Received:  0  Reflected:  0  Queued:  0  Sent:  1  Environmental  Received:  0  Control  Received:  1  Control 
Received:  1 

[11.0,  2:13:37.54]  cpQ  CONTROLLER  -  END  RESPOND  OUTPUT 

[11.0,  2:13:37.54]  SimViewer_expframe.expframe.expframe.cpg.cpgcontroller:  Internal  transition 

[1 1.0,  2:13:37.54]  SimViewer_expframe.expframe.expframe.cpg.cpgcontroller:  Internal  transition  from  Respond 

[1 1.0,  2:13:37.54]  SimViewer_expframe.expframe.expframe.cpg.cpgcontroller:  Holding  in  phase  Passive  for  time  Infinity 

[11.0,  2:13:37.54]  CPG  CONTROLLER  -  START  RESPOND  INTERNAL 

[1 1.0,  2:13:37.69]  CPG  Controller  -  internal  event  for  Respond  -  time  Elapsed:  NA  getTimeAdvance:  Infinity  clock:  1 1.0 
[1 1.0,  2:13:37.69]  Pulses  Received:  0  Reflected:  0  Queued:  0  Sent:  1  Environmental  Received:  0  Control  Received:  1  Control 
Received:  1 

[1 1.0,  2:13:37.69]  CPG  Controller  -  Ending  Respond  internal  transition 
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[1 1.0,  2:13:37.69]  SimViewer_expframe.expframe.expframe.cpg.cpgcontroller:  Holding  in  phase  Passive  for  time  Infinity 
[11.0,  2:13:37.69]  CPG  CONTROLLER  -  END  RESPOND  INTERNAL 

[11.0,  2:13:37.69]  SimViewer_expframe.expframe.expframe.cpg. laser:  Received  messages  [inCtrlln:  LaserMsj^ 

io 

name:  CPG  Controller  FIRE  Response  Message  for  Case  1  Control  Message  1 
status:  6 
magnitude:  0.0] 

[11.0,  2:13:37.69]  SimViewer_expframe.expframe.expframe.cpg. laser:  External  transition 

[1 1.0,  2:13:37.69]  SimViewer_expframe.expframe.expframe.cpg.laser:  Holding  in  phase  UpdateLaser  for  time  0.0 
[11.0,  2:13:37.69]  @@**********«**  LASER  -  START  PASSIVE  CTRLIN  EXTERNAL 


[11.0,  2:13:37.69]  Laser  -  external  event  for  Passive  Ctrlln  with  Ctrlln  -  time  Elapsed:  11.0  getTimeAdvance:  0.0  clock:  11.0 
[1 1.0,  2:13:37.69]  Laser  is  set  to  ON 

[11.0,  2:13:37.69]  Laser  -  Preparing  laser  fire  control  message  for:  CPG  Controller  EIRE  Response  Message  for  Case  1  Control 
Message  1  to  port  CtrlOut 

[1 1.0,  2:13:37.69]  SimViewer_expframe.expframe.expframe.cpg. laser:  Holding  in  phase  UpdateLaser  for  time  0.0 
[11.0,  2:13:37.69]  @@**********«**  LASER  -  END  PASSIVE  CTRLIN  EXTERNAL 

[11.0,  2:13:37.69]  SimViewer_expframe:  Simulation  step  finished 
[11.0,  2:13:37.288]  SimViewer_expframe:  Simulation  step  started 
[11.0,  2:13:37.288]  @@*********«**«  UilER  -  START  UPDATELASER  OUTPllf 


[1 1.0,  2:13:37.288]  Laser  -  output  event  for  UpdateLaser  -  time  Elapsed:  NA  getTimeAdvance:  0.0  clock:  1 1.0 
[11  0  2T3'37  288]  **=:^*****=:^***=i^**=i^**=i^  DISPLAY  PULSES  IN  QUEUE  ******************* 

[1 1.0,  2:13:37.288]  Total  Number  of  Optical  Pulses  in  Queue  :  0  before  reflection. 

[11.0,  2:13:37.288] *************************************************************** 

[1 1.0,  2:13:37.288]  Pulses  Received:  0  Reflected:  0  Queued:  0  Sent:  0  Environmental  Received:  0  Control  Received:  1 
[11.0,  2:13:37.288]  @@*************  LASER  -  END  UPDATE, LASER  OUTPUT 


[11.0,2:13:37.303] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

EVENT********* 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

EVENT********* 

[11.0,2:13:37.319] 

[16.0,2:13:37.459] 

[16.0,2:13:37.459] 

EVENT********* 

[16.0,2:13:37.459] 

[16.0,2:13:37.459] 

[16.0,2:13:37.459] 

[16.0,2:13:37.459] 

[16.0,2:13:37.459] 

[16.0,2:13:37.459] 

[16.0,2:13:37.459] 

[16.0,2:13:37.459] 

EVENT********* 

[16.0,2:13:37.459] 

[16.0,2:13:37.459] 

[16.0,2:13:37.459] 

[16.0,2:13:37.459] 

EVENT********* 

[16.0,2:13:37.459] 


SimViewer_expframe.expframe.expframe.cpg. laser:  Internal  transition 
SimViewer_expframe.expframe.expframe.cpg. laser:  Internal  transition  from  UpdateLaser 
SimViewer_expframe.expframe.expframe.cpg. laser:  Holding  in  phase  Passive  for  time  Infinity 
@@*************  laser  -  START  UPDATELASER  INTERNAL 

Laser  -  internal  event  for  UpdateLaser  -  time  Elapsed:  NA  getTimeAdvance:  Infinity  clock:  1 1.0 
DISPLAY  PULSES  IN  QUEUE  ******************* 

Total  Number  of  Optical  Pulses  in  Queue  :  0  after  reflection. 

InterruptRespond  =  false 
needRespond  =  false 
laserpower  =  true 
currentStatus  =  6 
sendCtrl  status  is:  6 

Laser  -  Preparing  optical  pulse  for:  Laser  Output  Pulse  1  to  port  OptOutl 
Going  to  Create  Pulse  Phase  Next! !  I 

SimViewer_expframe.expframe.expframe.cpg. laser:  Holding  in  phase  CreatePulse  for  time  5.0 
@@*************  laser  -  END  UPDATE, LASER  INTERNAL 

SimViewer_expframe:  Simulation  step  finished 
SimViewer_expframe:  Simulation  step  started 
@@*************  LMER  -  START  CREATEPULSE  OUTPUT 

Laser  -  output  event  for  CreatePulse  -  time  Elapsed:  NA  getTimeAdvance:  5.0  clock:  16.0 
DISPLAY  PULSES  IN  QUEUE  ******************* 

Total  Number  of  Optical  Pulses  in  Queue  :  0  BEEORE  propagation. 

**  OUTPUT  EVENT  EOR  CREATEPULSE 

###  Laser  -  Sending  generated  optical  pulse:  Laser  Output  Pulse  1  to  port  OptOutl 

Pulses  Received:  0  Reflected:  0  Queued:  0  Sent:  1  Environmental  Received:  0  Control  Received:  1 

@@*************  laser  -  END  CREATEPULSE  OUTPUT 

SimViewer_expframe.expframe.expframe.cpg. laser:  Internal  transition 
SimViewer_expframe.expframe.expframe.cpg. laser:  Internal  transition  from  CreatePulse 
SimViewer_expframe.expframe.expframe.cpg. laser:  Holding  in  phase  Passive  for  time  Infinity 
@@*************  laser  -  START  CREATEPULSE  INTERNAL 

Laser  -  internal  event  for  CreatePulse  -  time  Elapsed:  NA  getTimeAdvance:  Infinity  clock:  16.0 
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[16  0  2'13'37  459]  DISPLAY  PULSES  IN  QUEUE 

[16.0,  2:13:37.459]  Total  Number  of  Optical  Pulses  in  Queue  :  0  BEEORE  propagation. 

[16.0,  2:13:37.459] *************************************************************** 

[16  0  2’13'37  459]  *****h<**h<**h«**h«  Adjust  queue  ***^h<*^h<*h«h<**h«* 

[16.0,  2:13:37.459]  Total  Number  of  Optical  Pulses  in  Queue  :  0 

[16.0,  2:13:37.459]  SimViewer_expframe.expframe.expframe.cpg. laser:  Holding  in  phase  Passive  for  time  Infinity 
[16.0,  2:13:37.459]  @@*************  LASER  -  END  CREATEPULSE  INTERNAL 


[16.0,  2:13:37.459]  SimViewer_expframe.expframe.expframe.cpg.pmfiberl:  Received  messages  [inOptInl:  OpticalPulse 
id:  1 

name:  Laser  Output  Pulse  1 

duration:  4.0E-10 

opticalPower:  8.709666395E-5 

brightPulsePlg:  false 

amplitude:  1.94095418E-6 

centralErequency:  1.0E15 

globalPhase:  0.0 

ellipticity:  0.0 

orientation:  0.0 

numberOfGaussians:  3 

gAO:  45.5 

gAl:  38.064 

gA2:  4.75752 

gM0:9.54844E-ll 

gMl:  1.81125E-10 

gM2:  3.52322E-10 

gSDO:  1.98151E-11 

gSDl:  5.81389E-11 

gSD2:  4.90169E-11] 

[16.0,  2:13:37.459]  SimViewer_expframe.expframe.expframe.cpg.pmfiberl:  External  transition 


The  following  is  the  CPG  Controller  External  Transition  code  for  receiving  a 
message  when  in  Passive  phase  on  port  “Ctrllni”  (from  appendix  U).  If  the  controller 
receives  a  message  while  Passive  on  this  port,  it  store  the  value  of  the  message  in  variable 
ctrlOutput  and  checks  the  status  type  of  the  message  by  checking  ctrlMsg. status.  If  this 
type  is  “init”  or  “get  status”  the  output  port  is  set  to  CtrlOuti  or  if  the  type  is  “fire  laser” 


the  port  is  set  to  CtrlOuti. 


Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower,  e,  ((p,,v,),.... 

iPn,Vn)))  = 

(“respond”,  0,  store,  temperature,  overtemp,  overpower,  lastCDPower) 


if  phase  =  “passive”  and  ^  =  “Ctrlln 


CtrlOutput  =  ctrlMsg(5tore) 
if  CtrlMsg.  status  =  “init”  or  “get  status’ 
outputPort  =  “CtrlOuti” 
if  CtrlMsg. status  =  “fire  laser” 
outputPort  =  “CtrlOuti” 
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Reviewing  the  CPG  Controller  Internal  Transition  code  shows  the  controller  will  always 
output  the  contents  of  the  ctrlOutput  variable  out  the  port  contained  in  the  outputPort 
variable.  Note  the  {outputPort,  ctrlOutput)  pair  is  a  (port, value)  binary. 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  = 

{outputPort,  CtrlOutput) 
if  phase  =  “respond” 

If  the  CPG  Controller  is  Passive  and  receives  a  message  on  Ctrllniwith  status  of 
“fire  laser,”  it  should  forward  the  message  on  port  CtrlOut2,  as  the  message  contents  are 
stored  in  ctrlOutput  in  the  external  transition  and  output  in  the  output  phase.  The  laser 
receives  this  message  and  constructs  and  emits  a  laser  pulse  per  its  DEVS  code  in 
appendix  M.  Note  that  the  test  time  of  propagation  for  components  is  five  time  units,  so  it 
should  take  the  laser  five  time  units  to  produce  an  optical  pulse.  The  next  component  in 
line,  PMFiberi,  should  receive  the  optical  packet  from  the  laser  (See  Figure  4). 

Reviewing  the  MS4ME  output,  the  controller  received  a  LaserMsg  with  id:l  at  time 
[11.0,  2:13:36.788]  on  port  Ctrllni.  The  expectation  is  if  the  message  is  the  “fire  laser” 
type,  the  controller  sends  the  fire  message  out  port  CtrlOut2,  which  happens  at  time  [1 1.0, 
2:13:37.54].  The  laser  receives  the  fire  message  at  time  [11.0,  2:13:37.69]  and  turns  the 
laser  on  to  create  a  laser  pulse.  The  laser  takes  five  time  units  to  create  the  optical  pulse 
and  sends  it  out  at  time  [16.0,  2:13:37.459].  The  next  component  in  line,  pmfiberl 
receives  the  optical  pulse. 

This  is  the  previous  block  of  MS4ME  output  winnowed  to  show  the  expected  behavior. 

[11.0,  2:13:36.788]  SimViewer_expframe.expframe.expframe.cpg.cpgcontroller:  Received  messages  [inCtrllnl:  LaserMsg 
id:  1 

name:  Case  1  Control  Message  1 
[11.0,  2:13:36.788]  CPG  Controller  received  a  laser  fire  message 

[1 1.0,  2:13:37.54]  ###  CPG  Controller  -  Sending  laser  fire  message:  CPG  Controller  FIRE  Response  Message  for  Case  1  Control 
Message  1  to  port  CtrlOut2 
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[11.0,  2:13:37.69]  SimViewer_expframe.expframe.expframe.cpg. laser:  Received  messages  [inCtrlln:  LaserMsg 
id:  1 

name:  CPG  Controller  FIRE  Response  Message  for  Case  1  Control  Message  1 
[11.0,  2:13:37.69]  Laser  is  set  to  ON 

[1 1.0,  2:13:37.319]  Laser  -  Preparing  optical  pulse  for:  Laser  Output  Pulse  1  to  port  OptOutl 
[1 1.0,  2:13:37.319]  Going  to  Create  Pulse  Phase  Next!!! 

[16.0,  2:13:37.459]  ###  Laser  -  Sending  generated  optical  pulse:  Laser  Output  Pulse  1  to  port  OptOutl 
[16.0,  2:13:37.459]  SimViewer_expframe.expframe.expframe.cpg.pmfiberl:  Received  messages  [inOptInl:  OpticalPulse 
id:  1 

name:  Laser  Output  Pulse  1 

Each  test  case  is  reviewed  in  the  same  manner  to  ensure  the  captured  output  matches  the 
expected  behavior  for  each  submodule  controller,  test  case,  and  component  behavior. 
Component  behavior  is  referenced  from  previously  captured  output  during  the  component 
testing. 

8.3.3  Closure  Under  Coupling 

One  of  the  significant  prosperities  of  DEVS  is  closure  under  coupling.  Simply 
stated,  if  any  result  from  coupling  components  specified  by  the  formalism  can  itself  be 
specified  by  the  formalism,  then  it  has  the  closure  under  coupling  property  (Barros,  1997; 
B.  P.  Zeigler,  1984).  Chow  showed  this  property  existed  in  the  Parallel-DEVS  formalism 
he  specified  in  1996  (Chow,  1996). 

The  coupled  submodules  discussed  earlier  in  this  chapter  exhibited  this  property 
during  testing  in  the  MS4ME  simulator.  DEVS  requires  explicit  definition  of  each 
message  type  or  input,  so  each  coupled  model  only  accepts  a  finite  set  of  inputs  and  the 
outputs  are  definable  under  Parallel-DEVS,  thereby  demonstrating  closure  under 
coupling. 

8.4  Summary 

This  chapter  presented  the  results  and  analysis  from  creation  and  testing 
methodology  the  atomic  and  coupled  DEVS  modules  for  the  qkdX  architecture.  This 
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research  effort  created,  modeled  and  tested  seventeen  optical  components  and  seven 
coupled  submodules  by  the  end  of  the  research  period.  The  research  produced  a 
combined  model  output  exceeding  7,300  pages  and  almost  200,000  lines  of  MS4ME 
code,  with  almost  five  times  as  much  code  devoted  to  testing  than  for  the  models 
themselves. 

As  there  was  no  automated  testing  available,  each  line  of  output  had  to  be 
checked  with  the  operational  simulator  graphics,  compared  to  the  lines  of  model  code  and 
the  DEVS  pseudocode,  based  on  the  mathematical  model  supplied  by  the  optical  SME. 
Einally,  after  successful  testing,  the  results  were  passed  to  the  optical  SME  for  final 
checking  to  ensure  the  proper  behavior  and  timing  was  captured  in  the  DEVS  pseudocode 
and  the  MS4ME  models.  This  was  a  cooperative  process  throughout,  with  the  optical 
SME  and  experts  from  the  AEIT  QKD  team  constantly  reviewing  the  progress  to  provide 
feedback  on  the  modeling  effort. 

As  the  models  developed,  they  evolved  closer  to  the  expected  system  behavior, 
until  each  was  deemed  acceptable  by  the  SMEs  and  research  team.  Using  the  definitions 
of  validity  discussed  earlier,  this  effort  provided  models  that  captured  the  required 
behavior  and  met  the  required  accuracy,  and  so  are  considered  “valid”  with  the 
understanding  this  validity  only  applies  to  the  models  built  for  the  specific  experimental 
frame.  These  “acceptable”  and  “valid”  models  increase  the  academic  rigor  of  the 
simulation  framework  by  providing  a  coherent  conceptual  modeling  methodology  using  a 
proven  modeling  formalism  that  demonstrates  the  required  and  expected  behavior. 

Using  DEVS  allowed  the  team  to  refine  the  simulation  framework,  correcting 
several  errors  and  aiding  the  research  team  in  recognizing  missing  behaviors  within  the 
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simulation  (see  chapter  7).  DEVS  increased  the  validity  of  QKD  simulation  framework 
optical  pathway  by  showing  DEVS  can  be  used  to  increase  validity  by  creating  optical 
component  models  fit  for  the  purposes  of  the  simulation  and  acceptable  to  the  community 
of  developers  and  users. 
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9.  Conclusions 


9.1  Chapter  Overview 

The  primary  objective  of  this  research  was  to  explore  the  use  of  the  DEVS  to 
create  conceptual  models  of  optical  components  for  use  in  the  qkdX  framework.  The  goal 
was  to  use  the  simulation  study  process,  conceptual  model  and  validity  theory,  and  DEVS 
to  contribute  to  the  QKD  sponsored  research  project.  This  chapter  presents  the 
conclusions  drawn  from  the  research  and  recommendations  for  future  work. 

9.2  Conclusions  of  Research 

The  research  into  DEVS  and  conceptual  modeling  highlighted  these  main  points: 

9.2.1  DEVS  Forces  ‘real-  time'  DES 

The  accepted  paradigm  in  DES  simulations  is  to  schedule  events  in  the  future.  As 
the  DES  moves  from  one  state  to  the  next,  this  list  is  checked  for  the  next  occurring 
event  and  the  time  in  the  simulator  jumps  to  the  event  execution  time.  This  makes  DES 
efficient,  as  the  simulation  ‘skips’  over  time  units  where  there  are  no  events.  The 
problem  occurs  when  events  cause  a  change  that  affects  future  events.  The  simulator 
must  be  able  to  correct  or  undo  any  future  event,  even  if  it  means  clearing  the  entire 
future  event  list  and  recalculating  every  event.  In  this  situation,  the  user  is  relying  on  the 
simulator  to  properly  correct  the  future  event  list,  expecting  no  mistakes  or  unforeseen 
simulation  behavior  from  these  changes. 

DEVS  differs  from  this  future  event  list  by  not  having  ‘future  time.’  DEVS  has 
two  types  of  time:  1)  time  the  state  will  stay  static;  2)  time  elapsed  since  the  last  state 


109 


transition.  The  modeler  cannot  schedule  events  in  the  future  and  must  specify  the  state 
transitions  from  one  state  to  the  next.  This  precludes  the  simulation  from  entering  an 
unexpected  state  and  prevents  emergent  behavior.  The  system  can  never  enter  a  state 
that  is  unrecoverable  (unless  that  was  the  intent)  and  so  prevents  the  Once  Passive, 
Never  Active  (OPNA)  condition  that  is  seen  in  complex  DBS  simulations. 

9.2.2  Discovery  of  Non-composability  in  qkdX 

One  of  the  sponsor  requirements  for  the  QKD  simulation  framework  is  that  of 
compos  ability.  The  simulation  must  be  able  to  change  components  and  modules  without 
extensive  code  change.  The  design  concept  was  for  a  “plug  and  play”  simulation  where 
users  can  easily  change  system  designs.  This  requirement  is  reflected  in  the  user  and 
developer  requirements  discussed  earlier  in  this  dissertation.  Ensuring  composability  is  a 
major  undertaking  for  the  research  project. 

During  the  creation  of  the  conceptual  models  for  each  of  the  optical  components 
and  coupled  submodules  led  to  discovery  of  problems  within  the  original  version  of  the 
qkdX  simulation  framework.  This  version  was  built  straight  from  the  SME  mathematical 
models  as  a  proof-of-concept  demonstration  without  using  formalized  conceptual  models, 
leaping  from  the  SME  modeling  level  to  the  simulation  coding  level  of  Figure  1  and 
using  a  “mental  model”  as  a  bridge  between  the  math  model  and  the  final  simulation. 
Time  and  resource  considerations,  along  with  the  intent  to  only  produce  a  demonstration 
simulation,  where  among  the  reasons  for  choosing  this  development  course.  See  Eigure  5. 
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Figure  5.  Abbreviated  Levels  of  Modeling  for  qkdX. 

Several  of  these  problems  would  have  prevented  the  optical  models  from 
executing  the  same,  regardless  of  how  they  were  connected,  while  others  were  incorrect 
expressions  of  component  behavior.  Using  DEVS  forces  the  modeler  to  carefully 
consider  how  each  model  behaves  under  all  conditions,  and  guarantees  the  models  exhibit 
closure  under  coupling  (see  chapter  7).  The  careful  consideration  of  behavior  required  by 
DEVS  decreases  the  likelihood  of  errors  or  missing  behaviors  during  the  conceptual 
modeling  phase. 

This  is  not  to  mean  that  having  complete  DEVS  models  ensures  the  simulation 
exhibits  composability.  While  the  modeling  relation  and  validity  measures  the  closeness 
of  the  conceptual  model  to  the  source  system,  the  simulation  relation  and  verification  is  a 
measure  of  how  well  the  simulation  executes  the  behavior  of  the  conceptual  models  (See 
Eigure  6,  modified  from  (B.  P.  Zeigler,  Praehofer,  &  Kim,  2000)). 
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Figure  6.  Modified  from  “Basic  entities  in  M&S  and  their  relationships”. 

The  skills,  talents,  and  experience  of  the  modelers  responsible  for  turning  the  conceptual 

modeling  into  an  executable  simulation,  along  with  verification  testing,  determine  if  the 

final  simulation  exhibits  compos  ability.  In  this  case,  composable  DEVS  models  do  not 

guarantee  qkdX  is  itself  composable.  The  closer  the  simulation  executes  the  required 

behavior,  the  greater  the  chance  of  composability  and  by  using  DEVS,  the  better  chance 

of  capturing  all  required  behavior. 

9.2.3  Well-defined  Behavior 

A  concern  for  complex  DES  simulation  is  ill-defined  or  emergent  behavior  that 
leads  to  the  simulation  entering  a  state  or  condition  it  cannot  leave  (known  as  OPNA). 
Simple  simulations  can  be  checked  by  evaluating  every  possible  state,  but  with  a  large 
simulation,  the  state-space  becomes  unmanageable  and  infeasible  to  check.  Project  time 
and  funds  limit  testing  for  simulations,  even  with  automated  support. 

In  contrast,  using  DEVS  for  modeling  prevents  these  types  of  problem  behaviors. 
DEVS  requires  the  modeler  to  identify  the  lowest  level  of  objects  in  the  simulation,  one 
that  cannot  be  further  decomposed  (atomic).  These  atomic  models  can  be  modeled 
regardless  of  their  immediate  context  (i.e.  the  component  is  isolated  from  any  outside 
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influences)  and  their  total  behavior  specified.  A  correctly  specified  model  operates 
properly  regardless  of  its  use  and  the  environment.  By  fully  specifying  the  atomic 
behavior,  the  modeler  is  assured  the  components  work  properly  when  connected,  in  any 
possible  combination  {closure  under  coupling).  This  allows  for  hierarchal  construction  of 
models  and  ensures  modularity  of  the  simulation. 

9.2.4  Tool-Independent  Form 

A  major  consideration  in  simulation  creation  is  selecting  the  software 
environment.  This  choice  can  have  long-term  effects  on  the  simulation,  as  a  poor  or  hasty 
choice  can  lead  to  a  failed  project.  This  selection  process  was  a  secondary  research 
question  discussed  in  chapter  2  and  discussed  in  chapter  5.  Some  simulation 
environments  have  their  own  programming  language  while  others  use  standard 
programming  languages  (i.e.  OMNeT-i-i-  uses  the  C-i-i-  language).  Each  language  may 
have  idiosyncrasies  that  prevent  easy  translation  from  one  simulation  environment  to 
another  (Miller,  2013a).  For  an  example,  the  Java  language  (used  in  MS4ME)  has 
routines  to  free  memory  storage  (garbage  collection)  but  C-i-i-  does  not;  the  Java  runtime 
system  has  ways  of  knowing  the  size  of  an  array,  but  the  C-i-i-  runtime  does  not  (Miller, 
2013a;  Miller,  2013b;  Miller,  2013c).  Understanding  these  examples  requires  some 
experience  in  programming,  but  do  highlight  there  are  language- specific  idiosyncrasies 
that  prevent  simple  conversations. 

DEVS  forces  the  modeler  to  consider  carefully  all  facets  of  desired  behavior 
within  the  model,  including  all  inputs,  outputs,  and  timing  segments.  The  resulting 
models  are  based  solely  on  the  language  rules  inherent  in  DEVS,  and  not  on  the  selected 
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simulation  environment.  This  allows  for  creation  of  models  usable  for  any  simulation 
environment.  The  modeler  needs  only  to  express  the  DEVS  behavior  in  the  simulator  of 
choice. 

9.2.5  Canonical  Behavior 

DEVS  forces  the  modeler  to  consider  carefully  all  aspects  of  the  conceptual  model, 
starting  with  the  inputs,  outputs  and  behaviors  of  interest  necessary  for  study.  This 
experimental  frame  greatly  reduces  or  eliminates  emergent  or  unexpected  behavior.  By 
considering  ‘real-time’  transitions,  well-defined  behavior  and  tool-independence,  the 
modeler  creates  a  deep  understating  of  the  system  usable  in  any  modeling  simulation.  By 
understanding  the  canonical  behavior  of  the  model,  the  modeler  can  implement  changes 
to  decrease  the  differences  between  the  model  and  the  referent  system,  thereby  increasing 
the  validity  of  the  model  for  the  chosen  experimental  frame. 

9.2.6  Difficulties  of  Modeling  Using  DEVS 

Much  of  the  written  material  available  for  DEVS  in  textbooks  and  papers 
provides  only  simplistic  examples.  Even  the  more  complex  examples  available  through 
RTSync  provided  little  guidance  to  model  the  optical  components.  This  complexity  led 
this  researcher  to  contact  the  co-director  of  Arizona  Center  for  Integrative  Modeling  and 
Simulation  (Arizona  State  University,  2014),  the  research  center  where  DEVS  was 
created,  for  advice  on  using  DEVS  for  our  unique,  innovative  models.  The  co-director 
provided  suggestions  on  how  to  use  DEVS  to  model  the  timing  issues  at  the  picosecond 
scale  and  capturing  wave  and  particle  behavior. 
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It  can  be  difficult  to  verify  the  DEVS  pseudocode  to  the  source  system  behavior, 
especially  true  when  modeling  predicted  or  notional  systems.  Since  the  demonstration 
QKD  system  is  built  from  real  optical  components  but  in  a  notional  architecture,  there 
was  the  diffieulty  of  verifying  the  component  behavior  to  real  components.  The  solution 
used  in  this  research  to  this  problem  greatly  increased  the  DEVS  work  by  necessitating 
programming  the  pseudocode  twice,  once  into  MS4ME,  and  then  into  the  selected  qkdX 
simulator. 

DES  models  are  increasing  in  complexity  and  being  used  in  new  information- 
centered  fields.  DEVS  was  not  created  for  these  types  of  problems  and  has  difficulty 
expressing  processes  and  information  flows  within  the  formalism.  Heretofore,  the 
solution  has  been  to  create  subsets  of  DEVS  to  handle  specific  problems.  This  is  leading 
to  a  fragmentation  of  the  formalism  and  makes  it  hard  to  determine  which  form  of  DEVS 
is  appropriate  for  the  modeling  problem.  This  research  used  the  Parallel-DEVS  formalism 
for  modeling  the  optical  path,  but  this  DEVS  may  not  be  applieable  to  modeling  the 
processes  found  in  QKD  systems. 

DEVS  is  a  set  of  language  rules  to  describe  formally  a  problem.  There  is  no  visual 
component  to  DEVS  unless  the  modeler  uses  a  DEVS -compliant  simulation  program. 
While  useful  for  being  tool-independent,  this  requires  the  modeler  to  use  that  particular 
simulator’s  functions,  which  may  not  necessarily  conform  completely  to  DEVS,  as  seen 
with  issues  in  EVOA  timing  and  the  MS4ME  simulator  (see  chapter  7). 
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9.3  Recommendations  for  Future  Research 


This  research  investigated  using  the  DEVS  to  create  conceptual  models  for  a 
prototypical  QKD  architecture.  The  scope  was  intentionally  narrowed  to  the  optical  path 
of  this  particular  architecture,  rather  than  to  try  to  model  every  identified  optical 
component.  During  the  research  period,  the  researcher  identified  additional  areas  for 
research  using  the  DEVS  formalism. 

The  AEIT  QKD  team  continues  to  build  on  the  qkdX  framework,  adding  new 
capabilities  to  model  other  types  of  QKD  systems.  This  research  used  weak-coherent 
polarization-based  system  architecture,  the  same  kind  as  the  first  QKD  system.  While 
useful  as  a  reference  baseline,  this  type  is  rarely  found  outside  of  academic  research 
systems  as  most  commercial  QKD  systems  use  a  phase-based  architecture.  The  AEIT 
team  is  adding  the  components  and  functions  necessary  to  model  these  systems,  as  each 
piece  of  new  hardware  needs  a  corresponding  conceptual  model,  so  there  is  a  continuing 
need  to  create  conceptual  models. 

An  intriguing  area  is  using  DEVS  to  express  the  functions  and  processes  inherent 
in  each  type  of  QKD  system.  This  research  focused  on  the  optical  path  hardware  in  the 
quantum  modules,  but  QKD  systems  have  many  processes  in  each  protocol.  DEVS  works 
well  with  state  machine  simulations,  but  it  is  unknown  if  it  could  be  used  to  create 
conceptual  models  for  complex  processes.  During  the  literature  review  for  this  research, 
no  examples  were  found  using  DEVS  to  model  processes,  but  as  there  is  continuing 
research  into  DEVS,  there  may  a  process-compatible  version  in  the  future. 

This  research  used  the  MS4ME  DEVS  simulator  as  a  test  platform  for  the  DEVS 
pseudocode.  Using  traces  of  the  output  allowed  for  checking  of  component  behavior. 
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Unfortunately,  there  was  no  automated  tool  for  checking  the  output,  so  the  researcher 
manually  reviewed  over  7000  pages  of  output.  This  took  considerable  time  and  effort  that 
slowed  the  research  process  by  taking  time  away  from  other  research  activities.  An 
automated  tool  for  checking  this  output  would  have  considerable  impact  on  the  time 
necessary  to  perform  traces  on  component  output. 

One  of  the  areas  included  for  research  during  the  prospectus  was  to  compare 
output  from  the  MS4ME  simulator  to  output  from  the  qkdX  simulation.  This  would  be 
exploration  of  the  modeling  relation  (see  Figure  2  in  chapter  7)  between  the  conceptual 
model  and  the  simulator.  Work  in  this  area  ceased  when  the  researcher  and  the  software 
SMEs  realized:  1)  exploring  this  relation  was  outside  the  scope  of  research  into  model 
validation;  2)  considerable  time  and  effort  was  necessary  to  enable  this  functionality,  as  it 
required  extensive  changes  to  both  simulators.  An  automated  comparison  tool  would  save 
considerable  effort  on  the  part  of  researchers  and  allow  for  a  standardized  process  to  test 
the  modeling  relation  between  the  conceptual  model  and  the  QKD  simulation. 

As  mentioned  in  chapter  2,  the  AFIT  QKD  team  received  a  QKD  system  late  into 
this  research  period.  A  future  research  project  could  be  to  model  the  real  system  using 
DEVS  and  MS4ME  and  compare  the  output  between  the  real  system  and  the  MS4ME 
models.  This  comparison  between  the  conceptual  models  and  a  real  system  would  be  an 
additional  V&V  technique  to  increase  the  validity  of  the  DEVS  models. 

The  work  presented  in  this  document  is  a  first  step  in  expressing  optical 
components  using  the  DEVS  formalism  and  increasing  the  validity  of  the  qkdX 
simulation  framework.  The  results  demonstrated  that  DEVS  can  create  conceptual 
models  of  continuous-time  optical  components  in  a  DBS  environment.  This  work  showed 
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that  DEVS  can  be  used  to  increase  the  validity  of  the  qkdX  simulation  thus  improving  the 
quality  of  the  simulation  and  possibly  increasing  its  d  value  to  the  project  sponsor  and 
future  end-users. 
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Appendix  A  -  QKD  Prototypical  Architecture 

This  appendix  contains  the  systems  engineering  material  created  during  the  selection  of 
the  prototypical  QKD  system  architecture.  Much  of  the  material  derives  from  the  Department  of 
Defense  Architectural  Framework  (DODAF),  currently  in  version  2.02  (Department  of  Defense, 
2010).  The  DODAF  is  a  comprehensive  framework  and  conceptual  model  that  enables 
architectural  development  and  allows  for  key  decisions  through  organized  information  sharing. 
The  framework  is  a  group  of  interrelated  models  and  views  of  the  project  that  allow  for 
accountability  and  traceability  throughout  the  design  process.  The  following  table  lists  the 
DODAF  views  presented  in  this  research. 


Table  1 .  List  of  DODAF  Views. 


DODAF  Views 

Equivalent  Work 

AV-1  Overview  and  Summary  Information 

Completed,  not  included 

AV-2  Integrated  Dictionary 

Continuing  updates,  not  included 

OV-1  High-Level  Operational  Concept  Graphic 

QKD  Context  Diagram 

OV-2  Operational  Resource  Flow  Description 

High  level  Resource  Flows  Diagram 

OV-5a  Operational  Activity  Decomposition  Tree 

Activity  Decomposition  Diagram 

OV-5b  Operational  Activity  Model 

Activity  Models 

SV-1  Systems  Interface  Description 

System  Interface  Graphic 

SV-2  Systems  Resource  Flow  Description 

System  Resource  Flows  Diagrams 

SV-5a  Operational  Activity  to  Systems  Function 
Traceability  Matrix 

Activity  to  Systems  Function  Matrix 

SV-5b  Operational  Activity  to  Systems  Traceability 
Matrix 

Subsystem  to  Activity  Matrix 

SV-lOa  Systems  Rules  Model 

Use  cases  for  components  and  modules  in  each 
appendix 

SV-lOb  Systems  State  Transition  Description 

Phase  transition  diagrams  in  each  appendix 

SV-lOc  Systems  Event-Trace  Description 

Event-trace  tables  and  diagrams  in  each 
appendix 

A.l  Systems  Engineering  Support 

The  information  presented  here  is  support  for  the  design  decisions  during  the  building  of 
the  prototypical  architecture,  but  was  not  included  for  discussion  in  the  articles  presented  in 
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Chapters  6  and  7,  as  neither  of  the  articles  focused  on  the  systems  engineering  aspects  of  the 
architecture.  The  end  of  this  chapter  presents  the  tools  used  during  the  research. 

A.  1.1  QKD  Context 

This  graphic  shows  the  high-level  concepts  for  the  QKD  system.  Here  Alice  uses 
quantum  exchange  to  pass  information  to  Bob.  Through  the  phases  of  sifting,  error  correction 
and  privacy  amplification,  a  final  key  is  generated  and  distributed  to  their  respective  encryptors 


QKD  System 


Classical  Channel 

Alice 

Quantum  Channel 

Bob 

. . 

Shared  KeyX 

Shared  Key  K 

T 

Plaintext  m 

Bulk 

Ciphertext 

Bulk 

Plaintext  m 

Encryptor 

High-Speed  Data  Link 

Encryptor 

Figure  1.  QKD  Context  Diagram. 

A.  1. 2  Activity  Decomposition 

This  graphic  shows  the  decomposition  of  the  BB84  QKD  system  into  levels  of 
operational  activities.  Each  level  is  color-coded  for  clarity.  The  QKD  activity  is  decomposed  into 
two  activities,  one  that  handles  the  initialization  of  the  system  and  one  that  handles  key 
generation  and  distribution. 
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2.1.2  Conduct 
Authentication 
Routines 

2.2  Rerform 
Calibration 

2 

2.2.1  Global 

/ 

2.3.1  Prepare 

Calibration 

/ 

Qubits 

2.8.1  Transform 


2.9.1  Hash  Final 


2.3.2  Send  Qubits 


2.4.1 

Communicate 
Detection  Bases 


2.8.2  Reduce  Key 


Figure  2.  QKD  Activity  Decomposition 


A.  1. 3  Activity  Model  -  Generate  Key 

This  graphic  represents  the  resouree  flows  within  the  Generate  Key  activity  seen  in  the 
activity  decomposition  diagram. 


Figure  3.  Generate  Key  Aetivity  Model. 
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A.  1. 4  Activity  Model  Decomposition-  Conduct  Quantum  Exchange 

This  graphic  represents  the  decomposition  of  the  Conduct  Quantum  Exchange  activity 
seen  in  the  activity  decomposition  diagram. 


Figure  4.  Decomposition  of  Conduct  Quantum  Exchange  Activities  part  1 . 


Figure  5.  Decomposition  of  Conduct  Quantum  Exchange  Activites  part  2. 


A.  1. 5  High  Level  Resource  Flows 
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This  graphic  shows  the  resources  flowing  between  Alice  and  Bob  within  a  QKD  system 
and  flowing  outside  to  their  respective  encryptors.  Note  that  the  encryptors  are  outside  the 
considered  system. 


System  Boundary 


Figure  6.  QKD  Resource  Flows. 

A.  1. 6  Systems  Interface  Graphic 

This  graphic  show  the  subsystems  located  within  Alice  and  Bob  and  the  communication 
channels  between  each  subsystem.  This  research  concentrates  on  the  Alice  Quantum  Module. 


System  Boundary 


Figure  7.  Alice  Systems  Interfaces. 


A.  1. 7  Systems  Resource  Flows  -  Alice  Quantum  Module 
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This  graphic  shows  the  sub  modules  within  the  Alice  Quantum  Module  and  the  data 
resouree  flow  between  eaeh.  Note  the  Environmental  message  ehannels  (ENV)  shown  here 
enable  the  passing  of  environmental  data  to  each  module  from  the  simulation  engine  and  enable 
the  modules  to  reaet  to  environment  ehanges.  These  ehannels  are  present  at  every  level  and  are 
not  shown  on  the  following  diagrams  for  clarity. 


Allice  Quantum  Module 


Env  -  Environmental  messages  pased  to  components.  Arrive  into  the  Alice  Quantum  Module  from  higher  simluaton  functions 
Opt  -  Optical  messages  passed  between  components.  The  Classical  Pulse  Generator  creates  optical  messages  in  its  laser 
Ctrl  •  Control  messages  passed  between  components 


Figure  8.  Alice  Quantum  Module  Resouree  Elows. 

The  following  graphies  show  the  deeomposition  of  the  Aliee  Quantum  Module 
subsystems  and  identify  the  individual  optieal  eomponents  within  subsystem.  The  graphies  show 
the  types  of  data  flowing  between  eaeh  eomponent.  Chapters  6  &  7  have  detailed  diseussions  on 
the  ereation  and  modeling  of  eaeh  sub  module  and  eomponent.  Note  eaeh  eomponent  has  an 
ENV  ehannel  as  noted  earlier. 
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Classical  Pulse  Generator 


System  Boundary 


Opt  -  Optical  messages  passed  between  components 

Ctrl  -  Control  messages  passed  between  components 

PM  •  Polarization-Maintaining  Optical  Fiber 

SM  -  Single  Mode  Optical  Fiber 

BP  Filter  -  Bandpass  Filter 

99/1  BS  -  99/1  Beamsplitter 

Class  Detector  -  Photo-diode  classical  detector 

Figure  9.  Classical  Pulse  Generator  Module. 


Pulse  Modulator 


System  Boundary 


Ctrl 

To  QM  Ctrir 

^Ctrl 

Opt 

^  Polarization  ^ 

Opt  _ 

PM 

^  Modulator  ^ 

SM 

Opt  -  Optical  messages  passed  between  components 
Ctrl  -  Control  messages  passed  between  components 
PM  -  Polarization-Maintaining  Optical  Fiber 
SM  -  Single  Mode  Optical  Fiber 


Decoy  State  Generator 


Ctrl 

*  To  QM  Ctrir 

Jctrl 

Opt 

Opt 

^  SM 

SM 

Opt  -  Optical  messages  passed  between  components 
Ctrl  -  Control  messages  passed  between  components 
PM  -  Polarization-Maintaining  Optical  Fiber 
SM  -  Single  Mode  Optical  Fiber 

EVOA  -  Electronically  controlled  Variable  Optical  Attenuator 


Figure  10.  Pulse  Modulator  and  Decoy  State  Generator  Modules. 
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Classical  to  Quantum 


System  Boundary 


Ctrl 


To  QM  Ctrir 


I 


Opt 

EVOA 

Opt  ^ 

Fixed  ^ 

SM 

* 

SM 

Attenuator 

Opt 


Opt  -  Optical  messages  passed  between  components 
Ctrl  -  Control  messages  passed  between  components 
PM  -  Polarization-Maintaining  Optical  Fiber 
SM  -  Single  Mode  Optical  Fiber 

EVOA  -  Electronically  controlled  Variable  Optical  Attenuator 

Figure  11.  Classical  to  Quantum  Module. 


Optical  Security  Layer 


System  Boundary 


Opt  -  Optical  messages  passed  between  components 
Ctrl  -  Control  messages  passed  between  components 
PM  -  Polarization-Maintaining  Optical  Fiber 
SM  -  Single  Mode  Optical  Fiber 
BP  Filter  -  Bandpass  Filter 

Class  Detector  -  Photo-diode  classical  detector 


Figure  12.  Optical  Security  Layer  Module. 
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Figure  13.  Timing  Pulse  Generator  Module. 


Output  Power  Monitor 

System  Boundary 

Ctrl 

^  To  QM  Ctrir 

Ctrl- Gate ^ 

fctr. 

? 

1 

Opt 

Opt 

Quantum 

Opt 

SM 

SM 

Channel 

Opt  -  Optical  messages  passed  between  components 

Ctrl  -  Click  -  Control  messages  passing  count  of  photons 

Ctrl  -  Gate  -  Control  messages  opening  gates  in  PNR 

PM  -  Polarization-Maintaining  Optical  Fiber 

SM  -  Single  Mode  Optical  Fiber 

Figure  14.  Output  Power  Monitor  Module. 

A.  1. 8  Activity  to  Systems  Function  Traceability  Matrices 

The  first  table  lists  the  systems  functions  identified  for  the  BB84  QKD  system  on  the  left 
and  shows  which  Activities  (See  Fig.  2)  each  function  supports.  The  areas  highlighted  in  yellow 
are  the  focus  of  this  research. 


Table  2.  Activity  to  Systems  Function  Matrix. 


System 

Function 

Operational  Activity 

Conduct  Power-on  Tests 

Perform  Loopback  Test 

Establish  Ethernet  Comms 

Conduct  Authentication  Routines 

Local  Calibration 

Global  Calibration 

Prepare  Qubits 

Send  Qubits 

Measure  Qubits 

Communicate  Detection  Bases 

Discard  Disagreeing  Bases 

Analyze  Classical  Error 

Analyze  Quantum  Error 

Segment  Sifted  Buffer 

Process  Segments 

Calculate  Entropy 

Transform  Buffer 

Reduce  Buffer 

flash  Final  Key 

Compare  Final  Key  Hash 

Distribute  Final  Key 

Check  power 

X 

Check  basic 
parameters 

X 

Check 

Ethernet 

controller 

X 

Check 

quantum 

module 

X 

Check  RNG 

X 

Check  System 
Ctrl 

X 
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Ethernet 

packet 

creation 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Ethernet 
packet  sending 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Ethernet 

packet 

receiving 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Authentication 

routine 

X 

Measure 

internal 

environment 

X 

Adjust 

parameters 

X 

X 

Measure 

quantum 

channel 

X 

Generate 

photon 

X 

Modulate 

photon 

X 

Attenuate 

photon 

X 

Store  qubit 
data 

X 

X 

Insert  timing 
pulse 

X 

Check  output 
power 

X 

Gate  detectors 

X 

Record 

detections 

X 

Retrieve  qubit 
data 

X 

X 

Compare  qubit 
data 

X 

Discard  qubit 
data 

X 

Compare  bit 
subset 

X 

Discard  bit 
subset 

X 

Chose  bit 
subset 

X 

X 

Calculate 

QBER 

X 

Calculate  stats 

X 

Compare  stats 

X 

Chose  block 
size 

X 

Segment  sifted 
key 

X 

EC  routine 

X 

Calculate 

entropy 

X 

Chose  hash 
function 

X 

X 

Compute 

matrix 

X 

X 

Select 

authentication 

seed 

X 

Compare  hash 

X 
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Distribute 
final  key 

X 

Distribute 

authentication 

seed 

X 

This  table  shows  Alice  and  Bob’s  subsystems  on  the  left  and  the  Activities  at  top,  showing  which 
subsystem  supports  each  of  the  Operational  Activities  from  Fig.  2. 

Table  3.  Subsystem  to  Activity  Matrix. 


System 

Operational  Activity 

Conduct  Power-on  Tests 

Perform  Loopback  Test 

Establish  Ethernet  Comms 

Conduct  Authentication 

Local  Calibration 

Global  Calibration 

Prepare  Qubits 

Send  Qubits 

Measure  Qubits 

Communicate  Detection 

Discard  Disagreeing  Bases 

Analyze  Classical  Error 

Analyze  Quantum  Error 

Segment  Sifted  Buffer 

Process  Segments 

Calculate  Entropy 

Transform  Buffer 

Reduce  Buffer 

Hash  F  inal  Key 

Compare  Final  Key  Hash 

Distribute  Final  Key 

Alice  System 
Controller  Module 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Alice  Public 
Channel 

Controller 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Alice  QRNG 

X 

X 

X 

X 

X 

Alice  Quantum 
Module 

X 

X 

X 

X 

X 

X 

Alice  Bulk 
Encryptor 

X 

Bob  System 
Controller  Module 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Bob  Public 

Channel 

Controller 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Bob  QRNG 

X 

X 

X 

Bob  Quantum 
Module 

X 

X 

X 

X 

X 

Bob  Bulk 

Encryptor 

X 
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A.  2  Selected  Research  Tools 


A.  2. 1  Software  Ideas  Modeler 

Software  Ideas  Modeler  rhttp://www.softwareideas.net/I  (SIM)  is  a  lightweight 
Computer-Aided  Software  Engineering  (CASE)  tool  that  provides  UML,  BPMN,  SysML,  ERD, 
Eloweharts,  Data  Elow  Diagrams,  Entity  Relationship  Diagram  (Crow  Eoot/Chen),  CRC  Cards, 
User  Interfaee,  Hierarehical  Task  Analysis,  Entity  Eife  History,  Robustness  Diagram, 
Coneurreney  Diagram,  Venn  Diagrams,  and  Mind  Map  tools.  All  of  the  diagrams  for  this 
researeh  were  ereated  in  SIM. 

SIM  was  ehosen  as  the  CASE  tool  over  the  more  extensive  system  engineering  tools  sueh 
as  Sparx  System’s  Enterprise  Architeet  (http://www.sparxsvstems.eom/products/ea/)  or  Vitech’s 
Core  (http://www.vitechcorp.com/products/core.shtml)  due  to  either  products  lack  of  support  for 
the  DEVS.  Such  tools  are  ultimately  designed  to  provide  support  for  rules-based  modeling  and 
even  support  simulation.  Since  neither  could  provide  support  for  DEVS  rules,  which  necessitated 
the  use  of  MS4ME  to  simulate  DEVS  models,  a  smaller  program  with  less  unnecessary  functions 
was  deemed  acceptable.  SIM  provided  ah  of  the  tools  necessary  to  create  the  various  products 
and  provided  linking  and  traceability  between  various  system  engineering  products.  See  Eigure 
15  for  a  screen  of  SIM  showing  the  project  overview  screen. 
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Figure  15.  Screenshot  of  Software  Ideas  Modeler. 
A.2.2  MS4ME 


MS4ME  (MS4  Systems,  2014).  MS4ME  is  a  requirements  engineering,  data  engineering 
and  modeling  and  simulation  tool  (http://www.ms4systems.com/pages/ms4me.php),  product  of 
RTSync  (www.rtsync.com),  a  spin-off  from  the  Arizona  Center  of  Integrative  Modeling  and 
Simulation  (ACIMS)  (Arizona  State  University,  2014).  MS4ME  provides  a  struetured  user 
interface  for  modeling  built  on  top  of  the  DEVSJAVA  simulator  (Zeigler,  Sarjoughian,  &  Au, 
1997). 

This  software  is  the  professional  successor  to  the  DEVS-Suite  simulator  built  by  students 
and  faeulty  of  ACIMS.  It  uses  the  DEVSJAVA  simulator  as  a  base  to  model  with  the  DEVS 
formalism  and  uses  the  Eclipse  (www.eclipse.org)  Integrated  Development  Environment  (IDE) 
as  the  user  interfaee.  MS4ME  provides  a  simulation  environment  using  the  DEVS  formalisms, 
specifieally  the  Finite-Deterministic  DEVS  (FD-DEVS)  and  Parallel-DEVS  of  DEVS.  This 
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research  used  Parallel  DEVS  to  model  the  optical  components,  as  discussed  in  Chapter  6.  See 
Fig.  16  for  screen  capture  of  MS4ME  simulator  function  running  the  CPG  module. 


Figure  16.  MS4ME  Screenshot. 
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Appendix  B-  Model  Creation  and  Testing  Methodology 

B.l  Atomic  and  Coupled  Model  Creation 

As  explained  in  Chapters  2  and  6,  the  process  for  creating  each  coupled  and  atomic 
model  consisted  of  many  steps.  The  general  process  for  the  optical  components  started  with  the 
optical  Subject  Matter  Expert  (SME)  creating  a  mathematical  model  of  the  component,  using  that 
model  to  create  Discrete  Event  System  Specification  (DEVS)  pseudocode  to  capture  the  behavior 
and  timing  aspects,  and  finally  creating  MS4ME  models  using  the  DEVS  pseudocode.  These 
models  underwent  testing  within  the  MS4ME  simulator,  with  the  results  shared  with  the  SME  for 
face  validity  and  trace  checking  (see  chapter  6  for  explanation  of  these  validation  techniques). 

Section  B.2  describes  the  component  behavior  testing  shows  an  example  of  the  MS4ME 
output  from  a  test  case  used  for  the  Electronically  Controlled  Variable  Optical  Attenuator 
(EVOA),  and  lists  pseudocode  derived  from  code  comments  win  the  EVOA  MS4ME  code.  Each 
component  was  designed  using  the  process  described  below.  Creation  and  testing  process  steps 
were: 

•  Component  description  -  describing  the  component  function  and  physical  design  using 
commercial  and  academic  literature. 

•  Component  conceptual  model  -  text  description  of  the  properties  and  behaviors  of 
interest  in  the  component. 

•  English-language  rules  -  list  of  rules  that  describe  the  behavior  of  the  component. 

•  Phase  transition  diagram  -  diagram  that  shows  how  the  component  moves  from  phase  to 
phase  within  each  state.  Chapter  6  describes  this  diagram  in  detail. 

•  Event  trace  diagram  -  diagrams  and  tables  describing  how  the  component  moves  from 
phase  to  phase  for  several  test  cases. 

•  Use  case  -  creating  use  cases  for  the  component. 

•  DEVS  code  -  DEVS  pseudocode  for  the  component;  used  to  create  the  MS4ME  models. 

•  MS4ME  code  -  programming  the  pseudocode  into  the  MS4ME  simulator  as  a  check  to 
ensure  the  pseudocode  captured  the  behavior  and  timing  properly. 
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•  MS4ME  output  review  -  a  line-by-line  eheck  of  the  MS4ME  output  to  ensure  the 
MS4ME  model  and  the  pseudocode  matched  and  the  MS4ME  programming  was  correct. 

•  MS4ME  model  review  -  the  optical  SME  reviewed  the  DEVS  conceptual  model  and  the 
MS4ME  models  to  ensure  the  modeled  behavior  and  timing  was  correct  in  comparison  to 
the  starting  mathematical  model. 

•  Model  refactor  -  after  review,  feedback  from  the  optical  SME  helped  correct  each  model. 
Appendices  D-T  contains  the  first  seven  steps  for  each  optical  component.  The  optical 

components  created  for  the  QKD  prototypical  architecture  were: 

Table  4.  Modeled  optical  components. _ 


Appendix 

# 

Title 

Contents 

D 

Bandpass  Eilter 

Component  description,  DEVS  documentation  &  Use 
Cases 

E 

Beamsplitter 

Component  description,  DEVS  documentation  &  Use 
Cases 

E 

Circulator 

Component  description,  DEVS  documentation  &  Use 
Cases 

G 

Photo-diode 

Component  description,  DEVS  documentation  &  Use 
Cases 

H 

EVOA 

Component  description,  DEVS  documentation  &  Use 
Cases 

I 

Eixed  Attenuator 

Component  description,  DEVS  documentation  &  Use 
Cases 

J 

Half-wave  Plate 

Component  description,  DEVS  documentation  &  Use 
Cases 

K 

In-line  Polarizer 

Component  description,  DEVS  documentation  &  Use 
Cases 

E 

Isolator 

Component  description,  DEVS  documentation  &  Use 
Cases 

M 

Easer 

Component  description,  DEVS  documentation  &  Use 
Cases 

N 

PM  Eiber 

Component  description,  DEVS  documentation  &  Use 
Cases 

0 

Polarization 

Controller 

Component  description,  DEVS  documentation  &  Use 
Cases 

P 

Pulse  Modulator 

Component  description,  DEVS  documentation  &  Use 
Cases 

Q 

Polarizing 

Beamsplitter 

Component  description,  DEVS  documentation  &  Use 
Cases 

R 

SM  Eiber 

Component  description,  DEVS  documentation  &  Use 
Cases 
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Component  description,  DEVS  documentation  &  Use 

s 

Optical  Switch 

Cases 

T 

WDM 

Component  description,  DEVS  documentation  &  Use 
Cases 

The  process  for  coupled  models  (joining  atomic  models  together)  followed  the  same 
design,  except  there  was  no  starting  mathematical  model  for  the  coupled  submodules;  therefore 
there  was  no  need  for  a  final  comparison  to  a  starting  mathematical  model  by  the  optical  SME. 
Appendices  W-AA  contains  the  documentation  for  each  of  the  coupled  submodules. 

Table  5  lists  the  coupled  submodules  created  for  the  QKD  prototypical  architecture. 

Table  5.  Modeled  Alice  submodules  components. _ 


Appendix 

# 

Title 

Contents 

U 

CPG  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

V 

PM  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

w 

DSG  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

X 

CTQ  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

Y 

OSL  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

Z 

TPG  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

AA 

0PM  Module 

Submodule  description,  DEVS  documentation  &  Use 
Cases 

B.2  Component  Behavior  Testing 

After  building  each  component  in  MS4ME,  it  was  tested  by  sending  inputs  into  the 
component,  capturing  the  output,  and  evaluating  the  output  line-by-line  to  check  behavior  and 
timing.  This  is  the  validation  technique  of  traces  (behavior  is  followed  through  the  model) 
(Sargent,  2005)  .  Each  component  had  each  of  its  input  ports  (optical,  environmental  (env), 
and/or  control  (ctrl))  tested  singly  and  in  different  combinations  of  ports  and  input  messages. 
After  identifying  and  correcting  any  errors,  the  component  was  retested  until  it  performed 


140 


correctly  for  each  test  case.  The  component  documentation  and  results  went  to  the  optical  SME 
for  review  to  ensure  the  proper  behavior  had  been  captured  (the  validation  technique  of  face 
validity  (Sargent,  2005)). 

Table  6.  Summary  of  component  behavior  testing,  captures  these  tests  by  listing  the 
component  on  the  left  and  the  number  and  test  types  across  the  top.  Each  component  will  be  in 
either  the  Passive  or  Respond  phase  when  reacting  to  inputs  (see  each  appendix  for  the  phase 
transition  diagram  showing  the  phases),  as  noted  at  the  top  of  the  table.  The  number  of  tests 
exercising  the  particular  port  type  is  in  the  boxes.  The  first  column  lists  the  total  number  of  tests, 
the  following  columns  lists  the  number  of  tests  exercising  a  particular  port  (optical,  Ctrl,  or  env) 
and  how  many  tests  are  single  or  multi-port,  and  finally  the  number  of  math-specific  tests.  These 
optical  SME  created  these  math  tests  to  exercise  the  demonstration  QKD  simulation  built  earlier 
and  but  were  included  in  the  MS4ME  code  for  potential  future  work  in  comparing  the  conceptual 
models  to  the  qkdX framework  (see  chapter  7  for  a  discussion  on  this  framework). 


Table  6.  Summary  of  component  behavior  testing. 


Passive  Phase 

Respond  Phase 

total  tests 

optical 

ports 

Ctrl 

port 

env 

port 

single 

port 

multiple 

port 

math 

tests 

total 

tests 

optical 

ports 

Ctrl 

port 

env 

port 

single 

port 

multiple 

port 

math 

tests 

Bandpass  Filter 

21 

20 

0 

13 

5 

16 

4 

21 

21 

0 

13 

4 

17 

0 

Beamsplitter 

33 

28 

0 

21 

9 

24 

6 

33 

33 

0 

21 

8 

25 

0 

Circulator 

27 

26 

0 

17 

6 

21 

6 

27 

27 

0 

17 

6 

21 

0 

Classical 

Detector 

21 

14 

14 

13 

5 

16 

7 

21 

21 

14 

13 

1 

20 

0 

EVOA 

30 

24 

13 

18 

6 

24 

7 

22 

22 

9 

11 

2 

19 

0 

Fixed 

Attenuator 

21 

20 

0 

13 

5 

16 

7 

21 

21 

0 

13 

4 

17 

0 

Halfwave  plate 

21 

20 

0 

13 

5 

16 

8 

21 

21 

0 

13 

4 

17 

0 

Inline  Polarizer 

29 

20 

0 

13 

5 

16 

7 

21 

21 

0 

13 

4 

17 

0 

Isolator 

29 

20 

0 

13 

5 

16 

7 

21 

21 

0 

13 

4 

17 

0 

Laser 

21 

14 

14 

13 

5 

16 

7 

21 

21 

15 

13 

2 

19 

0 

Optical  Switch 

35 

29 

14 

19 

7 

28 

8 

27 

27 

10 

12 

2 

25 

0 

PM  Fiber 

21 

20 

0 

13 

3 

18 

7 

21 

21 

0 

13 

4 

17 

0 

Polarization 

Controller 

30 

24 

13 

18 

6 

24 

8 

22 

22 

9 

11 

2 

20 

0 
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Polarization 

Modulator 

30 

24 

13 

18 

6 

24 

8 

1 

22 

22 

9 

11 

2 

20 

0 

Polarizing 

Beamsplitter 

33 

28 

0 

21 

9 

24 

7 

1 

33 

33 

0 

21 

8 

25 

0 

SM  Fiber 

21 

20 

0 

13 

3 

18 

7 

1 

21 

21 

0 

13 

4 

17 

0 

Wave  Division 
Multiplexer 

27 

26 

0 

17 

4 

23 

7 

1 

27 

27 

0 

17 

6 

21 

0 

Table  7.  Example  test  case  timing  chart  -  -CFCM.shows  the  case  timing  chart  for  the 
EVOA  eomponent.  The  first  ten  eolumns  of  this  ehart  list  the  test  eases,  and  the  last  five  show 
the  sequenee  of  test  eases  and  subeases  during  the  testing.  The  ehart  has  a  numbered  list  of  test 
eases  on  the  left  by  type  (Passive,  Respond,  or  Math)  and  information  about  eaeh  test  ease  aeross 
the  top.  Eaeh  ease  shows  whieh  port  it  is  exereising,  the  numbers  in  the  eells  show  many 
messages  sent  to  eaeh  port  during  the  test  ease,  and  finally  a  note  about  timing  of  the  messages. 
The  messages  ean  be  a  single  message  to  a  port,  messages  that  arrive  at  the  same  time,  or 
messages  that  arrive  at  different  times.  The  last  three  eolumns  for  the  test  eases  show  the  running 
total  of  eaeh  message  type  sent  to  the  eomponent  during  the  test.  The  bottom  of  the  eolumns 
show  total  message  numbers  and  a  notes  seetion  for  the  test  eases,  any  of  whieh  are  highlighted 
in  orange. 

To  test  an  optieal  port,  an  optieal  message  is  injeeted  into  that  port  when  the  eomponent 
is  in  Passive  or  Respond  phase.  This  tests  eomponent  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  eomponent  is  interrupted  during  message  proeessing. 
Control  messages  work  in  the  same  way,  but  foree  the  eomponent  to  begin  behavior  to  reaet  to 
the  eontents  of  the  messages.  Environmental  paekets  foree  an  immediate  response  to  the  ehange 
in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

Eor  example.  Test  Case  26  starts  the  component  in  the  Passive  phase  and  injects  two 
messages  to  port  optical  1  (Optl),  one  message  to  optical  port  2  (Opt2),  one  message  each  to  the 
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control  and  environmental  ports,  all  done  at  the  same  time.  The  intent  of  the  case  is  to  see  if  the 
component  responds  correctly  to  external  inputs  while  it  is  processing  optical  packets.  The  first 
optical  packets  when  the  component  is  in  Passive,  forcing  a  change  of  phase.  While  processing 
the  packet,  the  other  three  packets  arrive  simultaneiously.  This  causes  the  component  to  interrupt 
the  current  process  and  respond  by  evaluating  the  incoming  packet.  After  the  response,  the 
component  needs  to  restart  processing  the  first  packet  while  updating  the  time  remaining  its 
processing.  This  component  phase  transition  chart  shows  this  behavior. 

At  the  end  of  the  case,  32  optical,  1 1  environmental  and  ten  control  messages  have  been 
sent  to  the  component.  As  with  all  test  cases,  the  component  showed  the  proper  behavior  at  the 
conclusion  of  the  case  verified  by  tracing.  Any  errors  found  during  testing  were  fixed  and  the 
component  retested  until  passing  all  test  cases. 


Table  7.  Example  test  case  timing  chart  -  EVOA. 


Phase 

Case 

Inject  Ports 

Optl  Opt2  Ctrl  Env 

Timing 

Running  Totals 
opt  #  env  #  Ctrl  # 

Passive 

1 

1 

0 

0 

0 

single 

1 

0 

0 

2 

0 

1 

0 

0 

single 

2 

0 

0 

3 

0 

0 

1 

0 

single 

2 

0 

1 

4 

0 

0 

0 

1 

single 

2 

1 

1 

5 

1 

1 

0 

0 

same  time 

4 

1 

1 

6 

1 

0 

1 

0 

same  time 

5 

1 

2 

7 

1 

1 

0 

0 

differ  time 

7 

1 

2 

8 

1 

0 

1 

0 

differ  time 

8 

1 

3 

9 

1 

1 

1 

1 

same  time 

10 

2 

4 

10 

1 

1 

1 

1 

differ  time 

12 

3 

5 

11 

0 

1 

0 

1 

same  time 

13 

4 

5 

12 

0 

1 

0 

1 

differ  time 

14 

5 

5 

13 

0 

0 

1 

1 

same  time 

14 

6 

6 

14 

0 

0 

1 

1 

differ  time 

14 

7 

7 

15 

1 

0 

0 

1 

same  time 

15 

8 

7 

16 

1 

0 

0 

1 

differ  time 

16 

9 

7 

20 

2 

0 

0 

0 

same  time 

18 

9 

7 

21 

0 

2 

0 

0 

same  time 

20 

9 

7 

22 

2 

1 

0 

0 

same  time 

23 

9 

7 
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23 

2 

0 

1 

0 

same  time 

25 

9 

8 

24 

2 

0 

0 

1 

same  time 

27 

10 

8 

25 

2 

0 

1 

0 

differ  time 

29 

10 

9 

26 

2 

1 

1 

1 

same  time 

32 

11 

10 

27 

2 

1 

1 

1 

differ  time 

35 

12 

11 

28 

0 

2 

0 

1 

same  time 

37 

13 

11 

29 

0 

2 

0 

1 

differ  time 

39 

14 

11 

30 

0 

0 

1 

1 

same  time 

39 

15 

12 

31 

0 

0 

1 

1 

differ  time 

39 

16 

13 

32 

2 

0 

0 

1 

same  time 

41 

17 

13 

33 

2 

0 

0 

1 

differ  time 

43 

18 

13 

totals 

27 

16 

13 

18 

Respond 

41 

2 

0 

0 

0 

single 

45 

18 

13 

42 

1 

1 

0 

0 

single 

47 

18 

13 

43 

1 

0 

1 

0 

single 

48 

18 

14 

44 

1 

0 

0 

1 

single 

49 

19 

14 

45 

2 

1 

0 

0 

same  time 

52 

19 

14 

46 

2 

0 

1 

0 

same  time 

54 

19 

15 

47 

2 

0 

0 

1 

differ  time 

56 

20 

15 

48 

2 

0 

1 

0 

differ  time 

58 

20 

16 

49 

2 

1 

1 

1 

same  time 

61 

21 

17 

50 

2 

1 

1 

1 

differ  time 

64 

22 

18 

51 

1 

1 

0 

1 

same  time 

66 

23 

18 

52 

1 

1 

0 

1 

differ  time 

68 

24 

18 

60 

3 

0 

0 

0 

same  time 

71 

24 

18 

61 

1 

2 

0 

0 

same  time 

74 

24 

18 

62 

3 

1 

0 

0 

same  time 

78 

24 

18 

63 

3 

0 

1 

0 

same  time 

81 

24 

19 

64 

3 

0 

0 

1 

same  time 

84 

25 

19 

65 

3 

0 

1 

0 

differ  time 

87 

25 

20 

66 

3 

1 

1 

1 

same  time 

91 

26 

21 

67 

3 

1 

1 

1 

differ  time 

95 

27 

22 

68 

1 

2 

0 

1 

same  time 

98 

28 

22 

69 

1 

2 

0 

1 

differ  time 

101 

29 

22 

totals 

43 

15 

9 

11 

Math 

TCI 

1 

0 

1 

2 

same  time 

102 

31 

23 

TC2 

1 

0 

1 

2 

same  time 

103 

33 

24 

TC3 

1 

0 

1 

2 

same  time 

104 

35 

25 

TC4 

1 

0 

1 

2 

same  time 

105 

37 

26 

TC5 

1 

0 

1 

2 

same  time 

106 

39 

27 

TC6 

1 

0 

1 

2 

same  time 

107 

41 

28 

TC7 

1 

0 

0 

2 

same  time 

108 

43 

28 

144 


totals 


_2_ 

11 


_o 

31 


_6 

28 


U 

43 


totals 
Notes: 

8  -  Set  attenuation  message,  set  newattenuation  =  2 
10  -  Get  attenuation  message 

1 3  -  Increase  attenuation  message 

14  -  Decrease  attenuation  message 

23  -  INIT  control  message  sent;  OPTl  &  Ctrl  -  same  time  -  Passive:  downstream  received  packets  =  214 
30  -  INIT  control  message  sent  -  Ctrl  &  ENV  -  same  time  -  Passive:  downstream  received  packets  =  214 
63  -  INIT  control  message  sent  -  OPTl  &  Ctrl  -  same  time  -  Respond:  downstream  received  packets  =  211 
65  -  Set  attenuation  message,  set  newattenuation  =  5 

67  -  INIT  control  message  sent  -  OPTl,  OPT2,  Ctrl  &  ENV  -  differ  time  -  Respond:  downstream  received  packets  = 
207 

B.2.1  MS4ME  Testing  Structure 

The  testing  eonstruet  for  eaeh  eomponent  and  eoupled  module  is  the  same.  There  is  test 
eomponent  ealled  “Upstream”  that  injeets  messages  into  the  eomponent  under  test  and  there  is  a 
testing  eomponent  called  “Downstream”  that  captures  all  output  from  the  component  under  test. 
These  two  constructs  contain  all  of  the  logic  for  the  testing  cases,  as  the  component  only  has 
logic  to  react  to  inputs.  Figure  17  shows  the  testevoa  module  with  the  three  components,  each 
component  labeled  with  its  current  phase  and  ports.  As  noted  earlier.  Upstream  only  has  (out)put 
ports  connected  to  the  EVOA  (in)put  ports,  and  all  of  the  EVOA  (out)put  ports  are  connected  to 
Downstream’s  (in)put  ports.  Since  the  EVOA  does  not  output  env(ironmental)  messages,  there 
are  is  no  env  input  port  in  Downstream.  Each  optical  component  listed  in  Table  4  has  a  similar 
testing  construct  built  in  MS4ME. 
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Figure  17.  EVOA  testing  structure  in  MS4ME 

B.2.2  MS4ME  Sample  EVOA  Output 


Eollowing  this  paragraph  is  output  from  MS4ME  while  running  the  EVOA  component. 
This  is  the  output  from  Test  Case  2  (highlighted  in  Table  6)  and  starts  at  simulation  time  20. 
Major  events  described  in  this  paragraph  are  highlighted  in  yellow  in  the  MS4ME  output.  An 
optical  pulse  with  id  number  2  enters  the  EVOA  at  simulation  time  21.0.  The  attenuator  reacts  to 
the  input  with  an  external  event  during  the  Passive  phase  on  optical  port  2  (OptIn2).  The  packet 
is  added  to  the  queue  and  the  attenuator  transitions  from  Passive  to  Reflect  phase.  The 
component  reflects  a  portion  of  the  packet  out  to  the  Downstream  module  and  enters  the  Reflect 
internal  transition.  During  the  Reflect  phase  internal  transition,  the  queued  packet  is  removed 
from  the  queue,  attenuated,  and  set  to  output  during  the  Respond  output  phase.  Once  in  the 
Respond  phase,  the  packet  is  output  and  the  queue  checked  during  the  Respond  internal 
transition.  Since  the  queue  contains  zero  packets,  the  EVOA  returns  to  the  Passive  phase  and 
finally.  Downstream  receives  the  attenuated  optical  packet  at  simulation  time  26.  This  time 
checks  properly  as  the  propagation  time  for  the  EVOA  is  set  to  five  for  this  test  case  (26-21=5). 
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[20.0,  1:54:00.675]  SimViewer  testevoa:  Simulation  step  started 

[20.0,  1:54:00.675]  Upstream  -  output  event  for  Waitl  -  time  Elapsed:  NA  getXimeAdvance:  9.0  clock:  20.0 
[20.0,  1:54:00.676]  SimViewer  testevoa.testevoa.testevoa. Upstream:  Internal  transition 
[20.0,  1:54:00.676]  SimViewer  testevoa.testevoa.testevoa.Upstream:  Internal  transition  from  Waitl 
[20.0,  1:54:00.677]  SimViewer  testevoa.testevoa.testevoa.Upstream:  Holding  in  phase  Case2  for  time  0.0 
[20.0,  1:54:00.678]  SimViewer  testevoa:  Simulation  step  finished 
[20.0,  1:54:00.685]  SimViewer  testevoa:  Simulation  step  started 

[20.0,  1:54:00.685]  Upstream  -  output  event  for  Case2  -  time  Elapsed:  NA  getXimeAdvance:  0.0  clock:  20.0 
[20.0,  1:54:00.686]  SimViewer  testevoa.testevoa.testevoa.Upstream:  Internal  transition 
[20.0,  1:54:00.686]  SimViewer  testevoa.testevoa.testevoa.Upstream:  Internal  transition  from  Case2 
[20.0,  1:54:00.686]  SimViewer_testevoa.testevoa.testevoa.Upstream:  Holding  in  phase  Case2_l  for  time  1.0 
[20.0,  1:54:00.686]  Upstream  -  internal  event  for  Case2  -  time  Elapsed:  NA  getXimeAdvance:  1.0  clock:  20.0 
[20.0,  1:54:00.686]  Upstream  -  internal  event  for  Case2  -  time  Elapsed:  NA  getXimeAdvance:  0.0  clock:  20.0 
[20.0,  1:54:00.687]  SimViewer  testevoa:  Simulation  step  finished 
[21.0,  1:54:00.703]  SimViewer_testevoa:  Simulation  step  started 

[21.0,  1:54:00.704]  Upstream  -  output  event  for  Case2_l  -  time  Elapsed:  NA  getXimeAdvance:  1.0  clock:  21.0 
[21.0,  1:54:00.704]  SimViewer  testevoa.testevoa.testevoa.Upstream:  Internal  transition 
[21.0,  1:54:00.704]  SimViewer  testevoa.testevoa.testevoa.Upstream:  Internal  transition  from  Case2_l 
[21.0,  1:54:00.705]  SimViewer_testevoa.testevoa.testevoa.Upstream:  Holding  in  phase  Wait2  for  time  9.0 
[21.0,  1:54:00.705]  Upstream  -  internal  event  for  Case2_l  -  time  Elapsed:  NA  getXimeAdvance:  9.0  clock:  21.0 
[21.0,  1:54:00.705]  Upstream  -  internal  event  for  Case2_l  -  time  Elapsed:  NA  getXimeAdvance:  1.0  clock:  21.0 
[21.0,  1:54:00.705]  SimViewer_testevoa.testevoa.testevoa.evoa:  Received  messages  [inC)ptln2:  OpticalPulse 
id:  2 

name:  Case  2  Optical  Pulse  2 
duration:  4.0E-10 
opticalPower:  8.709666395E-5 
brightPulseFlg:  false 
amplitude:  |E94095418E^ 
centralFrequency:  1.0E15 
globalPhase:  0.0 
ellipticity:  0.0 
orientation:  0.0 
numberOfGaussians:  3 
gAO:  45.5 
gAl:  38.064 
gA2:  4.75752 
gMO:  9.54844E-11 
gMl:  1.81125E-10 
gM2:  3.52322E-10 
gSDO:  1.98151E-11 
gSDl:  5.81389E-11 
gSD2:4.90169E-ll] 

[21.0,  1:54:00.706]  SimViewer_testevoa.testevoa.testevoa.evoa:  External  transition 

[21.0,  1:54:00.706]  SimViewer_testevoa.testevoa.testevoa.evoa:  Holding  in  phase  Reflect  for  time  0.0 

[21.0,  1:54:00.706]  @@*************  BVOA  -  SXARX  PASSIVE  OPX1N2  EXXERNMi 


[21.0,  1:54:00.706] 
[21.0,  1:54:00.706] 
[21.0,  1:54:00.706] 
[21.0,  1:54:00.706] 
[21.0,  1:54:00.706] 
[21.0,  1:54:00.706] 
[21.0,  1:54:00.706] 
[21.0,  1:54:00.706] 
[21.0,  1:54:00.706] 
[21.0,  1:54:00.706] 
[21.0,  1:54:00.706] 
[21.0,  1:54:00.706] 
EVENT********* 


EVOA  -  external  event  for  Passive  with  OptIn2  -  time  Elapsed:  5.0  getXimeAdvance:  0.0  clock:  21.0 
Pulses  Received:  2  Reflected:  1  Queued:  1  Sent:  1  Environmental  Received:  0  Control  Received:  0 
EVOA  -  received  optical  pulse  named  :  Case  2  Optical  Pulse  2  at  time  :  21.0 
Passive  External  -  Adding  pulse  to  queue 

DISPLAY  PULSES  IN  QUEUE  ******************* 

Xotal  Number  of  Optical  Pulses  in  Queue  :  1 

ID:  2  Name:  Case  2  Optieal  Pulse  2  PortNum:  2  Reflected:  false  Xime  Remaining:  5.0 

Pulses  Received:  2  Reflected:  1  Queued:  2  Sent:  1  Environmental  Received:  0  Control  Received:  0 
EVOA  -  Preparing  reflected  pulse:  Reflected  Case  2  Optical  Pulse  2  for  sending  on  port  OptOut2 
Reflected  pulse  ID:  2  Name:  Reflected  Case  2  Optical  Pulse  2  PortNum:  2  Reflected:  true  Xime  Remaining:  5.0 
(g(g*H.***********  EVOA  -  END  PASSIVE  OPXIN2  EXXERNAL 


[21.0,  1:54:00.707]  SimViewer  testevoa:  Simulation  step  finished 

[21.0,  1:54:00.713]  SimViewer  testevoa:  Simulation  step  started 

[21.0,  1:54:00.713]  @@*************  BVOA  -  SXARX  REFLECX  OUXPtni 


[21.0,  1:54:00.713]  EVOA  -  output  event  for  Reflect  -  time  Elapsed:  NA  getXimeAdvance:  0.0  clock:  21.0 
[21  0  l'54'OO  713]  =i==f=**=i==f=  *****=(=  *=!==(=****  display  PULSES  IN  QUEUE  ****************=1=** 

[21.0,  1:54:00.713]  Xotal  Number  ofOptical  Pulses  in  Queue  :  1  before  reflection. 

[21.0,  1:54:00.713]  ID:  2  Name:  Case  2  Optical  Pulse  2  PortNum:  2  Reflected:  true  Xime  Remaining:  5.0 

[21.0,  1:54:00.713]  ###  EVOA  -  Reflecting  pulse:  Reflected  Case  2  Optical  Pulse  2  to  port  OptOut2 
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[21.0,  1:54:00.714]  Current  Attenuation  =:  0.1 
[21.0,  1:54:00.714]  New  Attenuation  =:  0.1 

[21.0,  1:54:00.714]  Pulses  Received:  2  Reflected:  2  Queued:  2  Sent:  1  Environmental  Received:  0  Control  Received:  0 
[21.0,  1:54:00.714]  @@*************  eVOA  -  END  REFLECT  OUTPUT 

[21.0,  1:54:00.714]  SimViewer_testevoa.testevoa.testevoa.evoa:  Internal  transition 
[21.0,  1:54:00.715]  SimViewer_testevoa.testevoa.testevoa.evoa:  Internal  transition  from  Reflect 
[21.0,  1:54:00.715]  SimViewer_testevoa.testevoa.testevoa.evoa:  Flolding  in  phase  Respond  for  time  5.0 
[21.0,  1:54:00.715]  @@*************  BVOA  -  START  REFLECT  INTERNAE 


[21.0,  1:54:00.715]  EVOA  -  output  event  for  Reflect:  Total  Number  of  Optical  Pulses  in  Queue  :  1 
[21  0  l'54'OO  715]  =i==f=*******=i=*******=f=*  display  PULSES  IN  QUEUE  **=f=****=i=********=i=** 

[21.0,  1:54:00.715]  Total  Number  of  Optical  Pulses  in  Queue  :  1  after  reflection. 

[21.0,  1:54:00.715]  ID:  2  Name:  Case  2  Optical  Pulse  2  PortNum:  2  Reflected:  true  Time  Remaining:  5.0 

[21.0,  1:54:00.715]  Setting  up  the  pulse  -  polling  the  queue  and  REMOVING  FROM  QUEUE 

[21.0,  1:54:00.715]  **  INTERNAL  EVENT  FOR  RESPOND  -  Before  Calc  -  Amplitude:  1.94095418E-6 

[21.0,  1:54:00.715]  **  INTERNAL  EVENT  FOR  RESPOND  -  After  Calc  -  Amplitude:  1.918736261226321E-6 

[21.0,  1:54:00.715]  EVOA  -  Preparing  send  pulse:  Attenuated  Case  2  Optical  Pulse  2  to  port  OptOutl 

[21.0,  1:54:00.716]  SimViewer_testevoa.testevoa.testevoa.evoa:  Holding  in  phase  Respond  for  time  5.0 

[21.0,  1:54:00.716]  Current  Attenuation  =:  0.1 

[21.0,  1:54:00.716]  New  Attenuation  =:  0.1 

[21.0,  1:54:00.716]  @@*************  EVOA  -  END  REFLECT  INTERNAL  TRANSITION 


[21.0,  1:54:00.716]  SimViewer  testevoa.testevoa.testevoa.Downstream:  Received  messages  [inOptln2:  OpticalPulse 
id:  2 

name:  Reflected  Case  2  Optical  Pulse  2 

duration:  4.0E-10 

opticalPower:  8.709666395E-5 

brightPulseFlg:  false 

amplitude:  |L94095418E-il 

centralFrequency:  1.0E15 

globalPhase:  0.0 

ellipticity:  0.0 

orientation:  0.0 

numberOlGaussians:  3 

gAO:  45.5 

gAl:  38.064 

gA2:  4.75752 

gMO:  9.54844E-11 

gMl:  1.81125E-10 

gM2:  3.52322E-10 

gSDO:  1.98151E-11 

gSDl:  5.81389E-11 

gSD2:4.90169E-ll] 

[21.0,  1:54:00.717]  SimViewer  testevoa.testevoa.testevoa.Downstream:  External  transition 

[21.0,  1:54:00.717]  SimViewer  testevoa.testevoa.testevoa. Downstream:  Holding  in  phase  Passive  for  time  Infinity 

[21.0,  1:54:00.717]  Downstream  -  external  event  for  Passive  with  Optln2  -  time  Elapsed:  5.0  getTimeAdvance:  Infinity  clock:  21.0 

[21.0,  1:54:00.717]  Downstream  -  Received  :  3 

[21.0,  1:54:00.717]  Downstream  -  Received  Optical  Pulse  :  3  named  :  Reflected  Case  2  Optical  Pulse  2  at  time  :  21.0 

[21.0,  1:54:00.717]  SimViewer  testevoa:  Simulation  step  finished 

[26.0,  1:54:00.726]  SimViewer  testevoa:  Simulation  step  started 

[26.0,  1:54:00.727]  @@*************  BVOA  -  START  RESPOND  OUTPHl 


[26.0,  1:54:00.727] 
[26.0,  1:54:00.727] 
[26.0,  1:54:00.727] 
[26.0,  1:54:00.727] 
[26.0,  1:54:00.727] 
[26.0,  1:54:00.727] 
[26.0,  1:54:00.727] 
[26.0,  1:54:00.727] 
[26.0,  1:54:00.727] 
[26.0,  1:54:00.727] 
EVENT********* 


EVOA  -  output  event  for  Respond  -  time  Elapsed:  NA  getTimeAdvance:  5.0  clock:  26.0 
DISPLAY  PULSES  IN  QUEUE  ******************* 

Total  Number  of  Optical  Pulses  in  Queue  :  0  BEFORE  propagation. 

**  OUTPUT  EVENT  FOR  RESPOND  Amplitude:  1.918736261226321E-6 
###  EVOA  -  Sending  pulse:  Attenuated  Case  2  Optical  Pulse  2  to  port  OptOutl 
Current  Attenuation  =:  0.1 
New  Attenuation  =:  0. 1 

Pulses  Received:  2  Reflected:  2  Queued:  2  Sent:  2  Environmental  Received:  0  Control  Received:  0 
(g^*************  EVOA  -  END  RESPOND  OUTPUT 


[26.0,  1:54:00.727]  SimViewer_testevoa.testevoa.testevoa.evoa:  Internal  transition 
[26.0,  1:54:00.728]  SimViewer_testevoa.testevoa.testevoa.evoa:  Internal  transition  from  Respond 
[26.0,  1 :54:00.728]  SimViewer_testevoa.testevoa.testevoa.evoa:  Holding  in  phase  Passive  for  time  hrfinity 
[26.0,  1:54:00.728]  @@*************  BVQA  -  START  RESPOND  INTERNffl 
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[26.0, 

[26.0, 

[26.0, 

[26.0, 

[26.0, 

[26.0, 

[26.0, 

[26.0, 

[26.0, 

[26.0, 

[26.0, 

[26.0, 

[26.0, 


1:54:00.728] 

1:54:00.728] 

1:54:00.728] 

1:54:00.728] 

1:54:00.728] 

1:54:00.728] 

1:54:00.728] 

1:54:00.728] 

1:54:00.728] 

1:54:00.729] 

1:54:00.729] 

1:54:00.729] 

1:54:00.729] 


******** 


EVOA  -  internal  event  for  Respond  -  time  Elapsed:  NA  getTime Advance:  Infinity  clock:  26.0 
:(:^:f:4c:(:^^:(::f:^:(:^H:^*H:***  J3J5PLAY  PULSES  IN  QUEUE  ******************* 

Total  Number  of  Optical  Pulses  in  Queue  :  0  BEFORE  propagation. 

Total  Number  of  Optical  Pulses  in  Queue  :  0 

Pulses  Received:  2  Reflected:  2  Queued:  2  Sent:  2  Environmental  Received:  0  Control  Received:  0 
EVOA  -  Ending  Respond  internal  transition 
Going  to  Passive  Phase  Next! ! ! 

SimViewer  testevoa.testevoa.testevoa.feroa:  Etolding  in  ghase  Passive  for  time  Infini^ 

Current  Attenuation  =:  0.1 
New  Attenuation  =:  0. 1 

(g(g*H.***********  EVOA  -  END  RESPOND  INTERNAL 


[26.0,  1:54:00.729]  SimViewer  testevoa.testevoa.testevoa.Downstream:  Received  messages  [inOptlnl:  OpticalPulse 
id:  2 

name:  l&ttenuated  Case  2  Efetical  Pulse  2| 

duration:  4.0E-10 

opticalPower:  8.709666395E-5 

brightPulseFlg:  false 

amplitude:  |1. 9 1 873626 122632  lE^ 

centralFrequency:  1.0E15 

globalPhase:  0.0 

ellipticity:  0.0 

orientation:  0.0 

numberOfGaussians:  3 

gAO:  45.5 

gAl:  38.064 

gA2:  4.75752 

gMO:  9.54844E-11 

gMl:  1.81125E-10 

gM2:  3.52322E-10 

gSDO:  1.98151E-11 

gSDl:  5.81389E-11 

gSD2:4.90169E-ll] 

[26.0,  1:54:00.730]  SimViewer  testevoa.testevoa.testevoa.Downstream:  External  transition 

[26.0,  1:54:00.730]  SimViewer  testevoa.testevoa.testevoa.Downstream:  Flolding  in  phase  Passive  for  time  Infinity 

[26.0,  1:54:00.730]  Downstream  -  external  event  for  Passive  with  Optlnl  -  time  Elapsed:  5.0  getTimeAdvance:  bifinity  clock:  26.0 

[26.0,  1:54:00.730]  Downstream  -  Received  :  4 

[26.0,  1:54:00.730]  Downstream  -  Received  Optical  Pulse  :  4  named  :  Attenuated  Case  2  Optical  Pulse  2  at  time  :  26.0 
[26.0,  1:54:00.731]  SimViewer  testevoa:  Simulation  step  finished 


B.  2. 3  DE  VS  MS4ME  derived  pseudocode 

This  derived  pseudocode  is  an  example  of  the  logic  and  events  within  a  component,  and 
came  from  the  comments  placed  within  the  MS4ME  EVOA  module  code,  condensing  its  2600 
lines  of  code.  The  comments  were  placed  to  identify  actions  and  phase  transitions  to  increase 
readability  of  the  code  and  to  provide  markers  as  the  code  executes  during  runtime.  This 
pseudocode  show  a  major  process  for  the  EVOA  is  to  change  its  current  attenuation  setting  in 
response  to  control  input,  so  the  EVOA  includes  an  additional  phase  of  “Elpdate  Attenuation”  for 
this  operation.  See  appendix  H  for  the  detailed  description  of  the  EVOA. 
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EVOA  -  START  PASSIVE 


EVOA  -  START  PASSIVE  EXTERNAL  EVENT 
adjust  dock  based  upon  time  elapsed  since  last  event 
check  for  existing  optical  message 

remove  each  pulse  in  bag  and  store  it  into  a  queued  optical  pulse  buffer 
check  for  existing  env  message 

check  if  the  received  temperature  exceeds  damaged  or  degraded  threshold 
check  for  existing  Ctrl  message 

generate  the  response  message  for  an  incoming  control  message 
set  up  for  first  reflected  pulse  if  optical  pulse  arrived 
go  to  the  Reflect  phase  else  go  to  the  Update  Attenuation  phase 

EVOA  -  START  REFLECT  OUTPUT  EVENT 
adjust  clock  based  upon  time  advance 
output  pulse 

EVOA  -  START  REFLECT  INTERNAL  EVENT 
identify  any  pulses  that  have  not  yet  been  reflected  and  reflect  them 
set  up  pulse  to  send  in  Respond  phase 
go  to  the  Respond  phase 

EVOA  -  START  UPDATE  ATTENUATION  EXTERNAL  EVENT 
adjust  clock  based  upon  time  elapsed  since  last  event 
check  for  existing  optical  message 

remove  each  pulse  in  bag  and  store  it  into  a  queued  optical  pulse  buffer 
check  for  existing  env  message 

check  if  the  received  temperature  exceeds  damaged  or  degraded  threshold 
check  for  existing  Ctrl  message 

generate  the  response  message  for  an  incoming  control  message 
set  up  for  first  reflected  pulse  if  optical  pulse  arrived 
else  hold  in  the  Update  Attenuation  phase  for  a  change  in  Attenuation 

EVOA  -  START  UPDATE  ATTENUATION  OUTPUT  EVENT 
adjust  clock  based  upon  time  advance 
output  the  response  message 
change  the  current  attenuation 

EVOA  -  START  UPDATE  ATTENUATION  INTERNAL  EVENT 
set  up  pulse  to  send  in  Respond  phase  if  optical  pulse  arrived 
go  to  Respond  if  optical  pulse  arrived 
else  go  to  Update  Attenuation  if  a  control  message  arrived 
else  go  to  Passive 

EVOA  -  START  RESPOND  EXTERNAL  EVENT 
adjust  clock  based  upon  time  elapsed  since  last  event 
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adjust  queue 

set  a  flag  that  the  Respond  phase  was  interrupted  by  an  external  event 
check  for  existing  optical  message 

remove  each  pulse  in  bag  and  store  it  into  a  queued  optical  pulse  buffer 
check  for  existing  env  message 

check  if  the  received  temperature  exceeds  damaged  or  degraded  threshold 
check  for  existing  Ctrl  message 

generate  the  response  message  for  an  incoming  control  message 
set  up  for  first  reflected  pulse  if  optical  pulse  arrived 
go  to  the  Reflect  phase 
else  go  to  the  Update  Attenuation  phase 

EVOA  -  START  RESPOND  OUTPUT  EVENT 
adjust  clock  based  upon  time  advance 
adjust  pulse  amplitude  if  damaged  or  degraded 
output  pulse  to  the  correct  port 

EVOA  -  START  RESPOND  INTERNAL  EVENT 
adjust  queue 

check  if  there  any  pulses  remaining  in  queue 
set  up  the  next  queued  pulse 
pulses  remaining,  so  go  to  Respond 
else  check  to  see  if  the  attenuation  is  changing 
attenuation  changing,  go  to  Update  Attenuation 
else  go  to  Passive  phase 

EVOA  -  END  PASSIVE 


B.3  Coupled  Submodules 

The  component  testing  design  facilitated  building  the  coupled  submodules  by  replacing 
the  Upstream  and  Downstream  test  components  with  other  optical  components.  For  the  example 
of  the  Classical  Pulse  Generator  (CPG)  (see  appendix  U  and  chapter  6  for  discussion  of  the 
CPG),  the  ‘intemaT  of  the  submodule  is  built  of  optical  components  and  the  ‘external’  construct 
is  once  again  an  Upstream,  a  Downstream  and  the  CPG  acting  as  an  atomic  component,  in  this 
case  the  testing  construct  is  labeled  “expframe.”  This  is  the  benefit  of  DEVS’  closure  under 
coupling  (Chow,  1996;  Zeigler,  1976;  Zeigler,  1984)and  the  MS4ME  simulator  models  this 
behavior. 
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Each  coupled  submodule  was  tested  by  sending  messages  to  the  submodule  and  using  the 
operational  graphics  of  the  MS4ME  simulator  to  track  the  progress  of  the  message  through  the 
submodule.  The  primary  purpose  of  the  test  cases  was  to  test  the  ability  of  the  eoupled 
submodule  to  reeeive  messages  and  pass  them  internally  to  the  submodule  controller.  The 
eontroller  proeessed  the  message  and  passed  the  appropriate  message  to  the  controlled 
component.  Eor  example,  the  CFG  submodule  received  a  control  message  to  fire  the  laser.  The 
CFG  reeeived  the  message,  passed  it  internally  to  the  CFG  controller,  whieh  passed  the  message 
to  the  laser  eomponent,  whieh  fired  the  laser  to  emit  an  optieal  paeket.  There  are  four  or  five  test 
cases  for  each  submodule: 

•  Case  1  -  Send  a  eontrol  message  to  the  eoupled  submodule  to  exercise  the 
controller  and  eontrolled  eomponent.  For  each  of  the  modules: 

o  CFG  -  control  message  fires  laser, 
o  FM  -  control  message  ehanges  polarization, 
o  DSG  -  control  message  change  attenuation  of  EVOA. 
o  CTQ  -  control  message  change  attenuation  of  EVOA. 
o  OSE  -  control  message  requests  status, 
o  TFG  -  eontrol  message  fires  laser, 
o  OFM  -  control  message  change  switeh  position. 

•  Case  2  -  Send  a  control  message  to  request  the  status  of  the  eoupled  submodule, 
which  is  held  in  the  submodule  controller. 

•  Case  3  -  Send  an  environmental  message  to  the  coupled  submodule  for 
replieation  to  eaeh  component  within  the  module. 

•  Case  4-  Send  a  eontrol  message  to  the  coupled  submodule  that  contains  a  reset 
command. 

•  Case  5  -  Send  an  optieal  message  to  submodule  for  injection  into  optical  path 
within  the  submodule  (for  all  but  the  CFG). 

The  exeeptions  for  the  test  cases  were  the  CFG  and  the  OSE.  The  CFG  did  not  have  a  test 
case  to  inject  an  optical  packet  as  the  CFG  is  the  module  that  ereates  the  optieal  pulse,  though  it 
did  receive  refieetions  from  the  Downstream  module  into  the  CFG  OptIn2  port.  The  OSE  had 
one  less  control  message  as  its  “controlled”  device  is  the  classieal  detector,  which  only  sends 
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data  to  the  controller,  and  does  not  accept  input  control  messages.  See  Table  8  for  summary  of 
these  tests. 


Table  8.  Summary  of  coupled  submodule  behavior  testing. 


total 

tests 

Test  Type 

optical 

ports 

Ctrl 

port 

env 

port 

Classical  Fulse 

Generator 

4 

0 

3 

1 

Folarization  Modulator 

5 

1 

3 

1 

Decoy  State  Generator 

5 

1 

3 

1 

Classical  To  Quantum 

5 

1 

3 

1 

Optical  Security  Layer 

4 

1 

2 

1 

Timing  Fulse  Generator 

5 

1 

3 

1 

Optical  Fower  Monitor 

5 

1 

3 

1 

In  the  following  figures,  Figure  18  is  the  CFG  architecture  diagram.  Figure  19  is  the 
high-level  test  frame  and  Figure  20  shows  the  exploded  view  of  the  CFG  submodule  within  the 
high-level  test  frame.  Notice  there  is  a  “cpgcontroller”  that  receives  messages  from  outside  the 
CFG.  This  is  a  simple  representation  of  the  logic  circuits  necessary  to  operate  this  module.  In 
these  conceptual  models,  the  controller  reacts  to  the  appropriate  message  types  for  the  opto- 
electrical  components  connected  to  the  controller.  For  example,  the  CFG  controller  accepts 
messages  for  the  laser  and  the  classical  detector.  Similarly,  each  coupled  model  has  controller 
specific  for  its  needs. 
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Figure  19.  CPG  test  frame. 


Figure  20.  CPG  coupled  submodule  components. 

Connections  for  the  coupled  models  are  more  complex  than  for  the  individual 
components,  as  both  Upstream  and  Downstream  need  send  and  receive  messages  to  test  the 
external  CPG  submodule  ports,  and  environmental  messages  have  to  pass  through  into  the 
coupled  model  for  each  component. 

The  code  necessary  for  building  coupled  models  much  simpler  than  the  code  for  the 
components.  The  coupled  model  code  specifies  external  components  (Upstream,  Downstream) 
and  external  inputs  and  outputs  for  the  CPG  module.  Additionally,  the  code  lists  all  internal 
components  and  the  internal  connections  between  them.  Finally,  the  connections  from  the  CPG 
to  internal  components  are  defined.  For  a  coupled  model,  there  are  no  phases  or  transitions 
defined,  as  the  ‘state’  of  the  coupled  model  is  the  sum  of  all  current  states  of  all  internal 
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components.  Appendix  U  describes  the  CPG  in  detail  and  each  coupled  module  appendix  (U- 
AA)  has  the  DEVS  code  for  the  controller  and  the  coupled  module. 

Once  constructed,  each  coupled  model  was  tested  by  injecting  the  proper  message  packet 
into  the  submodule.  Every  coupled  model,  except  the  CPG,  has  input  optical,  environmental  and 
control  ports.  The  CPG  has  no  input  optical  port,  as  the  laser  within  the  CPG  generates  optical 
pulses  for  the  Alice  subsystem  and  its  primary  input  is  a  control  message  to  fire  the  laser.  Table  9 
summarizes  the  test  cases  for  the  CPG  submodule. 


Table  9.  Example  test  case  timing  chart  -  CPG. 


Inject  Ports 

Running  Totals 

Case 

Optl 

Ctrl 

Env 

Timing 

opt  # 

env  # 

Ctrl  # 

1 

0 

1 

0 

single 

0 

0 

1 

2 

0 

1 

0 

single 

0 

0 

2 

3 

0 

0 

1 

single 

0 

1 

2 

4 

0 

1 

0 

single 

0 

1 

3 

totals 

0 

3 

1 

B.3.1  MS4ME  Sample  CPG  Output 


This  section  contains  the  output  from  MS4ME  while  running  the  CPG  submodule.  This  is 
the  output  from  Test  Case  1  (highlighted  in  Table  9)  and  starts  at  simulation  time  10.  Major 
events  described  in  this  paragraph  are  highlighted  in  yellow  in  the  following  MS4ME  output. 
Case  1  starts  with  Upstream  having  an  output  event  at  time  10,  sending  the  message  to  the  CPG 
which  seamlessly  passes  the  message  inside  the  submodule  to  the  CPG  controller.  The  controller 
receives  a  EaserMsg  with  id;l  on  port  Ctrllnl  and  starts  the  Passive  external  event.  The 
controller  sees  it  has  received  a  laser  fire  message  and  moves  to  the  Respond  phase.  The 
controller  notes  that  the  status  number  of  the  message  is  6,  the  stored  power  value  of  the  last 
classical  detection  is  zero  (this  is  sent  from  the  classical  detector  when  it  has  a  detection)  and 
prepares  a  response  message  and  sends  it  out  port  CtlrOut2,  ending  the  Response  phase. 
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The  response  message  goes  to  the  laser,  which  receives  the  message  on  port  Ctrlln  and 
starts  the  Passive  Ctrlln  event.  The  laser  decodes  the  message,  moves  to  the  “ON”  setting  and 
prepares  a  fire  control  message  for  port  CtrlOut.  The  laser  moves  to  the  Update  Laser  phase 
where  it  notes  the  laserpower  variable  is  “true,”  indicating  the  laser  is  on.  The  laser  begins 
preparing  an  optical  pulse  for  output  on  OptOutl  (the  only  optical  output  port  in  the  laser)  and 
notes  it  is  moving  to  the  Create  Pulse  phase.  Once  in  the  Create  Pulse  phase,  the  laser  outputs  the 
generated  optical  pulse  on  port  OptOutl  and  ends  the  Create  Pulse  phase.  Finally,  the  next 
component  in  line  from  the  laser,  the  pmfiberl,  receives  the  optical  pulse  at  simulation  time  16. 
This  output  shows  how  the  CPG,  the  CPG  controller,  and  the  CPG  internal  laser  reacts  to  a  “fire 
laser”  message  to  generate  optical  pulses  at  the  beginning  of  the  optical  path  within  Alice. 


[10.0,  2:13:36.632]  SimViewer  expframe:  Simulation  step  started 

[10.0,  2:13:36.632]  Upstream  -  output  event  for  Casel  -  time  Elapsed:  NA  getXimeAdvance:  10.0  clock:  10.0 
[10.0,  2:13:36.632]  SimViewer  expframe.expframe.expframe. Upstream:  Internal  transition 
[10.0,  2:13:36.632]  SimViewer  expframe.expframe.expframe. Upstream:  Internal  transition  from  Casel 
[10.0,  2:13:36.632]  SimViewer_expffame.expframe.expframe. Upstream:  Holding  in  phase  Casel  l  for  time  1.0 
[10.0,  2:13:36.632]  Upstream  -  internal  event  for  Casel  -  time  Elapsed:  NA  getXimeAdvance:  1.0  clock:  10.0 
[10.0,  2:13:36.632]  Upstream  -  internal  event  for  Casel  -  time  Elapsed:  NA  getXimeAdvance:  10.0  clock:  10.0 
[10.0,  2:13:36.632]  SimViewer  expframe:  Simulation  step  finished 
[1 1.0,  2:13:36.773]  SimViewer  expframe:  Simulation  step  started 

[1 1.0,  2:13:36.788]  Upstream  -  output  event  for  Casel  l  -  time  Elapsed:  NA  getXimeAdvance:  1.0  clock:  1 1.0 

[1 1.0,  2:13:36.788]  SimViewer  expframe.expframe.expframe. Upstream:  Internal  transition 

[1 1.0,  2:13:36.788]  SimViewer  expframe.expframe.expframe. Upstream:  Internal  transition  from  Casel_l 

[1 1.0,  2:13:36.788]  SimViewer_expframe.expframe.expframe. Upstream:  Holding  in  phase  Waitl  for  time  49.0 

[11.0,  2:13:36.788]  Upstream  -  internal  event  for  Casel  l  -  time  Elapsed:  NA  getXimeAdvance:  49.0  clock:  1 1.0 

[1 1.0,  2:13:36.788]  Upstream  -  internal  event  for  Casel  l  -  time  Elapsed:  NA  getXimeAdvance:  1.0  clock:  1 1.0 

[11.0,  2:13:36.788]  SimViewer  expframe.expframe.expframe.cpg.cpgcontroller:  Received  messages  [inCtrllnl:  LaserMsg 

MU 

name:  Case  1  Control  Message  1 
status:  6 
magnitude:  0.0] 

[1 1.0,  2:13:36.788]  SimViewer  expframe.expframe.expframe.cpg.cpgcontroller:  External  transition 

[1 1.0,  2:13:36.788]  SimViewer  expframe.expframe.expframe.cpg.cpgcontroller:  Holding  in  phase  Respond  for  time  0.0 

[11.0,  2:13:36.788]  @@*************  CPG  CONTROLLER  -  START  PASSIVE  CTRLINl  EXTERNAL 

[11.0,  2:13:36.788]  CPG  Controller  -  external  event  for  Passive  Ctrlln  with  Ctrlln  -  time  Elapsed:  1 1.0  getTimeAdvance:  0.0  clock:  1 1.0 
[1 1.0,  2:13:36.788]  CPG  Controller  received  a  laser  fire  message 

[1 1.0,  2:13:36.788]  CPG  Controller  -  Preparing  laser  fire  control  message  for:  Case  1  Control  Message  1  to  port  CtrlOut2 
[1 1.0,  2:13:36.788]  SimViewer  expffame.expframe.expframe.cpg.cpgcontroller:  Holding  in  phase  Respond  for  time  0.0 
[1 1.0,  2:13:36.788]  @@*************  CPG  CONTROLLER  -  END  PASSIVE  CTRLINl  EXTERNAL 

[1 1.0,  2:13:36.944]  SimViewer  expframe:  Simulation  step  finished 
[11.0,  2:13:37.54]  SimViewer  expframe:  Simulation  step  started 

[11.0,2:13:37.54]  @@*************  EPG  CONTROLLER  -  START  RESPOND  OUTPlfll 

[1 1.0,  2:13:37.54]  CPG  Controller  -  output  event  for  Respond  -  time  Elapsed:  NA  getTimeAdvance:  0.0  clock:  1 1.0 

[11.0,  2:13:37.54]  sendCtrl  getStatus  =:  6 

[11.0,2:13:37.54]  Last  Classical  Detection  Optical  Power  =:  0.0 

[1 1.0,  2:13:37.54]  ###CPG  Controller  -  Sending  laser  fire  message:  CPG  Controller  FIRE  Response  Message  for  Case  1  Control  Message  1  to 
port  CtrlOut2 

[11.0,  2:13:37.54]  Pulses  Received:  0  Reflected:  0  Queued:  0  Sent:  1  Environmental  Received:  0  Control  Received:  1  Control  Received:  1 
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[11.0,  2:13:37.54]  @@*************  ^pQ  CONTROLLER  -  END  RESPOND  OUTPUT 

[1 1.0,  2:13:37.54]  SimViewer  expframe.expframe.expframe.cpg.cpgcontroller:  Internal  transition 

[1 1.0,  2:13:37.54]  SimViewer  expframe.expframe.expframe.cpg.cpgcontroller:  Internal  transition  from  Respond 

[1 1.0,  2:13:37.54]  SimViewer  expframe.expframe.expframe.cpg.epgcontroller:  Holding  in  phase  Passive  for  time  Infinity 

[11.0,  2:13:37.54]  @@*************  CPG  CONTROLLER  -  START  RESPOND  INTERNAL 

[1 1.0,  2:13:37.69]  CPG  Controller  -  internal  event  for  Respond  -  time  Elapsed:  NA  getTime Advance:  Infinity  clock:  1 1.0 

[1 1.0,  2:13:37.69]  Pulses  Received:  0  Reflected:  0  Queued:  0  Sent:  1  Environmental  Received:  0  Control  Received:  1  Control  Received:  1 

[11.0,  2:13:37.69]  CPG  Controller-  Ending  Respond  internal  transition 

[11.0,  2:13:37.69]  SimViewer  expframe.expframe.expframe.cpg.cpgcontroller:  Holding  in  phase  Passive  for  time  Infinity 
[11.0,  2:13:37.69]  @@*************  CPG  CONTROLLER  -  END  RESPOND  INTERNAL 

[1 1.0,  2:13:37.69]  SimViewer  expframe.expframe.expframe.cpg.laser:  Received  messages  [inCtrlhr:  LaserMsg 

io 

name:  CPG  Controller  FIRE  Response  Message  for  Case  1  Control  Message  1 
status:  6 
magnitude:  0.0] 

[11.0,  2:13:37.69]  SimViewer  expframe.expframe.expframe.cpg.laser:  External  transition 

[1 1.0,  2:13:37.69]  SimViewer  expframe.expframe.expframe.cpg.laser:  Holding  in  phase  UpdateLaser  for  time  0.0 
[1 1.0,  2:13:37.69]  @@*************  LASER  -  START  PASSIVE  CTRLIN  EXTERNAL 

[11.0,  2:13:37.69]  Laser  -  external  event  for  Passive  Ctrlln  with  Ctrlln  -  time  Elapsed:  11.0  getTimeAdvance:  0.0  clock:  1 1.0 
[11.0,  2:13:37.69]  Laser  is  set  to  ON 

[1 1.0,  2:13:37.69]  Laser  -  Preparing  laser  fire  control  message  for:  CPG  Controller  FIRE  Response  Message  for  Case  1  Control  Message  1  to  port 
CtrlOut 

[1 1.0,  2:13:37.69]  SimViewer  expframe.expframe.expframe.cpg. laser:  Holding  in  phase  UpdateLaser  for  time  0.0 
[11.0,  2:13:37.69]  @@*************  LASER-  END  PASSIVE  CTRLIN  EXTERNAL 


[11.0,  2:13:37.69]  SimViewer  expframe:  Simulation  step  finished 
[1 1.0,  2:13:37.288]  SimViewer  expfiame:  Simulation  step  started 
[11.0,2:13:37.288]  @@*************  LASER  -  START  UPDATELASER  OUTPUT 


[1 1.0,  2:13:37.288]  Laser  -  output  event  for  UpdateLaser  -  time  Elapsed:  NA  getTimeAdvance:  0.0  clock:  1 1.0 
[110  2'13'37  288]  dgpLAY  PULSES  IN  QUEUE  *****************=1=* 

[11.0,  2:13:37.288]  Total  Number  of  Optical  Pulses  in  Queue  :  0  before  reflection. 

[1 1.0,  2:13:37.288]  Pulses  Received:  0  Reflected:  0  Queued:  0  Sent:  0  Environmental  Received:  0  Control  Received:  1 
[11.0,2:13:37.288]  @@*************  LASER  -  END  UPDATELASER  OUTPUT 


[1 1.0,  2:13:37.303]  SimViewer_expffame.expframe.expframe.cpg. laser:  Internal  transition 
[1 1.0,  2:13:37.319]  SimViewer_expffame.expframe.expframe.cpg. laser:  Internal  transition  from  UpdateLaser 
[1 1.0,  2:13:37.319]  SimViewer_expffame.expframe.expframe.cpg. laser:  Holding  in  phase  Passive  for  time  Infinity 
[11.0,  2:13:37.319]  @@*************  LASER  -  START  UPDATELASER  INTERNAL 


[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

[11.0,2:13:37.319] 

******** 


Laser  -  internal  event  for  UpdateLaser  -  time  Elapsed:  NA  getTimeAdvance:  Infinity  clock:  1 1.0 
:(:^:f:4c:(:^^:(::f:^:(:^H:^*H:***  J3J5PLAY  PULSES  IN  QUEUE  ******************* 

Total  Number  of  Optical  Pulses  in  Queue  :  0  after  reflection. 

InteiTuptRespond  =  false 
needRespond  =  false 
laserpower  =  true 
currentStatus  =  6 
sendCtrl  status  is:  6 

Laser  -  Preparing  optical  pulse  for:  Laser  Output  Pulse  1  to  port  OptOutl 
Going  to  Create  Pulse  Phase  Next!!! 

SimViewer_expffame.expframe.expframe.cpg. laser:  Holding  in  phase  CreatePulse  for  time  5.0 
(g(g*H.***********  laser  -  END  UPDATELASER  INTERNAL 


[11.0,  2:13:37.319]  SimViewer  expframe:  Simulation  step  finished 

[16.0,  2:13:37.459]  SimViewer  expframe:  Simulation  step  started 

[16.0,  2:13:37.459]  @@*************  LASER  -  START  CREATEPULSE  OUTPUT 


[16.0,  2:13:37.459]  Laser  -  output  event  for  CreatePulse  -  time  Elapsed:  NA  getTimeAdvance:  5.0  clock:  16.0 
[16  0  2'13'37  459]  *******************  DISPLAY  PULSES  IN  QUEUE  ******************* 

[16.0,  2:13:37.459]  Total  Number  of  Optical  Pulses  in  Queue  :  0  BEFORE  propagation. 

[16.0,  2:13:37.459] *************************************************************** 

[16.0,  2:13:37.459]  **  OUTPUT  EVENT  FOR  CREATEPULSE 

[16.0,  2:13:37.459]  ###  Laser  -  Sending  generated  optical  pulse:  Laser  Output  Pulse  1  to  port  OptOutl 

[16.0,  2:13:37.459]  Pulses  Received:  0  Reflected:  0  Queued:  0  Sent:  1  Environmental  Received:  0  Control  Received:  1 
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[16.0,  2:13:37.459]  @@*^**^***^*^**  LASER  -  END  CREATEPULSE  OUTPUT 

[16.0,  2:13:37.459]  SimViewer  expframe.expframe.expframe.cpg. laser:  Internal  transition 
[16.0,  2:13:37.459]  SimViewer_expframe.expframe.expframe.cpg. laser:  Internal  transition  from  CreatePulse 
[16.0,  2:13:37.459]  SimViewer_expframe.expframe.expframe.cpg. laser:  Holding  in  phase  Passive  for  time  Infinity 
[16.0,  2:13:37.459]  @@^^^*****^^***  LASER  -  START  CREATEPULSE  INTERNAL 


[16.0,  2:13:37.459]  Laser  -  internal  event  for  CreatePulse  -  time  Elapsed:  NA  getTimeAdvance:  Infinity  clock:  16.0 
[16  0  2'13'37  459]  *******************  DISPLAY  PULSES  IN  QUEUE  ******************* 

[16.0,  2:13:37.459]  Total  Number  of  Optical  Pulses  in  Queue  :  0  BEFORE  propagation. 

[16  0  2'13'37  459]  ***************  Adjust  (^ueue  *************** 

[16.0,  2:13:37.459]  Total  Number  of  Optical  Pulses  in  Queue  :  0 

[16.0,  2:13:37.459]  SimViewer_expffame.expframe.expframe.cpg. laser:  ITolding  in  phase  Passive  for  time  brfmity 
[16.0,  2:13:37.459]  @@*************  LASER  -  END  CREATEPULSE  INTERNAL 


[16.0,  2:13:37.459]  SimViewer  explfame.expframe.expframe.epg.pmfiberl:  Received  messages  [inOptInl:  OptiealPulse 
id:  1; 

nUle:  Laser  Output  Pulse  1 
duration:  4.0E-10 
opticalPower:  8.709666395E-5 
brightPulseFlg:  false 
amplitude:  1. 940954 18E-6 
centralFrequency:  1.0E15 
globalPhase:  0.0 
ellipticity:  0.0 
orientation:  0.0 
numberOfGaussians:  3 
gAO:  45.5 
gAl:  38.064 
gA2:  4.75752 
gMO:  9.54844E-11 
gMl:  1.81125E-10 
gM2:  3.52322E-10 
gSDO:  1.98151E-11 
gSDl:  5.81389E-11 
gSD2:4.90169E-ll] 

[16.0,  2:13:37.459]  SimViewer  expffame.expframe.expframe.cpg.pmfiberl:  External  transition 
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Appendix  C  -  Cryptography  Overview 


The  need  for  secure  communications  has  existed  since  the  dawn  of  humanity. 
Cryptography,  the  practice  and  study  of  techniques  for  securing  communications  between  two 
authorized  parties  in  the  presence  of  one  or  more  unauthorized  third  parties,  is  an  essential  tool 
used  to  assure  information  security  (Piper  &  Murphy,  2002).  Historically,  government  and 
military  applications  are  the  chief  users  of  cryptography,  but  today  cryptography  provides 
security  services  to  almost  everyone,  including  confidentiality,  integrity,  authentication, 
authorization,  and  non-repudiation  (Barker  et  ah,  2005). 

C.l  Cryptosystems 

A  cryptosystem  is  composed  of  two  basic  components:  an  algorithm  and  one  or  more 
keys.  The  algorithm  is  the  mathematical  transformation  used  to  encrypt  and  decrypt  messages 
and  the  key(s)  are  parameters  used  in  the  encryption  and  decryption  processes.  Figure  1  shows  a 
block  diagram  of  a  simple  cryptosystem.  The  original  message,  m,  called  the  “plaintexf’ 
transforms  into  the  “ciphertext”,  EK{m),  using  the  encryption  algorithm,  E,  and  the  encryption 
key,  K.  The  terms  plaintext  and  ciphertext  refer  to  binary  data  and  can  represent  anything  in 
digital  form  (e.g.,  text,  audio,  video,  pictures,  and  programs).  Other  parameters  (e.g., 
initialization  vectors,  salt,  etc.)  may  be  used  but  are  not  shown  for  simplicity.  Ideally,  the 
ciphertext  is  not  decipherable  unless  you  possess  the  matching  decryption  key.  The 
transformation  of  plaintext  into  ciphertext  “protects”  the  confidentiality  of  messages  transmitted 
over  a  public  channel  where  an  adversary  could  possibly  intercept  it.  Upon  receipt,  the  ciphertext 
message  is  transformed  back  into  the  plaintext,  m,  using  the  decryption  algorithm,  D,  and  the 
decryption  key  K'.  The  decryption  algorithm,  D,  is  the  inverse  transformation  of  the  encryption 
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algorithm,  M,  which  means  that  DK'  (EK(m))=m.  Note  that  in  general  K  does  not  have  to  equal 
K',  although  it  does  for  symmetric  algorithms. 


m  — ' 
plaintext 


EicCm) 

ciphertext 


encryption  key 


eavesdropping 

adversary 


decryption  key 


Ok’  (EkChi))  =  m 
plaintext 


Figure  21.  A  Simple  Cryptosystem  Block  Diagram 


There  are  three  basics  types  of  cryptographic  algorithms;  symmetric,  asymmetric  and 
hashing  functions.  Symmetric  key  algorithms  use  the  same  key  (e.g.,  K  =  K')  for  encryption  and 
decryption.  The  benefits  of  a  symmetric  key  algorithm  are  that  it  provides  confidentiality,  is  fast, 
is  easily  implemented  in  hardware,  and  consumes  little  computational  power  when  compared  to 
asymmetric  algorithms.  However,  symmetric  key  algorithms  only  provide  confidentiality  and 
require  a  separate  key  for  each  pair  of  entities  who  wish  secure  communications,  which  does  not 
scale  well  when  large  numbers  of  entities  must  securely  communicate.  Examples  of  symmetric 
key  algorithms  include  the  Data  Encryption  Standard  (DES),  3-DES,  AES,  Blowfish,  Rivest 
Cipher  4  (RC4),  and  Rivest  Cipher  5  (RC5)  (Eoepp  &  Wootters,  2006;  Piper  &  Murphy,  2002; 
Schneier,  1995). 


Asymmetric  key  algorithms  used  mathematically  related,  but  different  (e.g.,  K  ^  K'),  key 
pairs  for  encryption  and  decryption  (e.g.,  public  and  private  keys)  which  reduces  the  key 
distribution  burden.  The  benefits  of  an  asymmetric  key  algorithm  are;  1)  no  need  for  “out  of 
band”  (sending  the  key  through  a  different  channel  than  the  encryption  channel)  key  distribution 
as  public  keys  are  freely  shared,  2)  it  scales  better  since  each  individual  only  a  needs  a  single 
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key-pair,  3)  provides  authentieation  and  non-repudiation.  However,  asymmetrie  key  algorithms 
are  slow  because  they  require  complex  mathematical  operations  and  typically  consume  more 
computational  power  than  symmetric  algorithms.  Examples  of  asymmetric  algorithms  include 
the  Rivest  Shamir  Adleman  (RSA),  Pretty  Good  Privacy  (PGP),  El  Gamal,  Elliptic  Curve 
Cryptography  (ECC),  and  Diffie -Heilman  (Eoepp  &  Wootters,  2006;  Piper  &  Murphy,  2002; 
Schneier,  1995). 

Hash  algorithms  are  one-way  functions  that  take  an  arbitrary-length  message  and  create  a 
fixed-length  message  digest.  Hash  algorithms  may  or  may  not  require  a  key  depending  on  their 
mode  of  operation.  Hashing  provides  an  efficient  way  to  check  the  integrity  of  stored  or 
transmitted  data  without  having  to  compare  the  data  bit  by  bit.  However,  since  hash  algorithms 
map  all  possible  inputs  to  a  fixed  length  message  digest,  more  than  one  input  can  map  to  the 
same  digest  creating  a  “collision”  which  may  provide  an  advantage  to  an  eavesdropper. 
Examples  of  hash  algorithms  include  Message  Digest-4  (MD-4),  Message  Digest-5  (MD-5),  and 
Secure  Hash  Algorithm-1  (SHA-1)  (Eoepp  &  Wootters,  2006;  Piper  &  Murphy,  2002;  Schneier, 
1995). 

C.2  The  One-Time  Pad  (OTP) 

The  only  cryptographic  algorithm  mathematically  proven  as  unconditionally  secure  is  the 
OTP.  The  OTP  is  a  symmetric  cryptographic  algorithm  and  is  relatively  easy  to  understand.  The 
first  known  description  of  the  OTP  was  in  1882  when  Frank  Miller  described 
“superencipherment”  as  a  means  to  insure  the  privacy  and  secrecy  of  telegraphic 
communications  (Bellovin,  2011).  Miller’s  method  required  the  use  of  a  randomly  created  key 
that  was  never  reused.  In  1917,  Gilbert  Vemam  invented,  and  later  patented,  a  cipher  based  on 
teleprinter  technology,  but  it  was  vulnerable  as  it  reused  key  material  (Vernam,  1919;  Vernam, 
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1926).  Despite  this  weakness,  a  National  Security  Agency  (NSA)  report  identified  Vernam’s 
patent  as  “perhaps  one  of  the  most  important  in  the  history  of  cryptography”  (Kahn,  1996).  In  the 
1940s,  Claude  E.  Shannon  proved  the  theoretical  significance  of  the  security  of  the  OTP  (C.  E. 
Shannon,  1949). 

The  strength  most  modern  cryptographic  algorithms  relies  on  “computational  security,” 
meaning  the  algorithm  is  considered  secure  if  there  is  a  negligible  probability  of  determining  the 
key  in  a  “reasonable”  amount  of  time  using  current  technology  (Schneier,  1995).  In  theory,  every 
cryptographic  algorithm,  except  the  OTP,  is  breakable  if  an  adversary  has  enough  captured 
ciphertext,  computational  resources,  and  time.  However,  the  OTP  is  not  commonly  used  due  to 
the  large  amount  of  non-reusable  key  material  required  to  properly  use  the  algorithm.  To  take 
advantage  of  the  OTP,  the  sender  (historically  known  as  Alice)  creates  and  distributes  random 
secret  keys  to  the  receiver  (historically  known  as  Bob)  equal  in  length  to  all  messages 
exchanged.  In  practice,  this  places  a  significant  burden  on  key  distribution  and  management  as 
one  must  continually  generate  and  securely  distribute  key  pads  between  the  senders  and  receivers 
(Schneier,  1995).  Historically,  the  OTP  is  only  used  in  environments  which  justify  the  costs 
involved  with  secure  key  distribution  (Singh,  1999). 

C.3  Computational  Security 

Along  with  problems  in  key  distribution,  there  are  concerns  that  certain  cryptographic  algorithms 
will  become  useless  when  quantum  computers  with  large  number  of  quantum  bits  (qubits) 
become  available.  Each  qubit  allows  a  quantum  computer  to  perform  in  a  single  step  what  takes 
multiple  steps  in  existing  computers  (Nielsen  &  Chuang,  2010).  This  allows  a  quantum  computer 
to  complete  difficult  tasks  much  sooner  than  a  regular  computer,  such  as  the  factoring  of  large 
numbers  (Shor,  1997).  Unfortunately,  most  current  encryption  algorithms  rely  on  the  factoring  of 
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large  numbers  being  a  hard  or  insurmountable  problem  for  computers,  so  quantum  computing 
would  risk  the  security  of  these  schemes  (Institute  for  Quantum  Computing,  2013) 
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Appendix  D  -  Bandpass  Filter 


D.l  Device  Description: 


The  Bandpass  filter  is  a  deviee  that  allows  light  around  a  central  frequency  to  pass  through 
in  either  direction,  along  with  a  small  band  of  frequencies  on  either  side  of  the  central  frequency. 
The  filter  creates  a  Fabry-Perot  etalon  (Saleh  &  Teich,  1991)  (cavity)  to  create  destructive 
interference  to  block  light  outside  of  the  “pass  through”  area.  The  passband  region  is  “tent” 
shaped  with  small  bands  on  either  side.  See  Figure  1  for  an  example  of  this  “tent”  structure. 

- %  Tf.arisrTd$sioii  (Forv^rcij  FWHM  =  JQ  nm) 

- %  Transmission  FWHM  -  40  nrti) 

- Transmission  (Forward,  FWHM  =  lOntrt) 


%  Transmission  (Badcward,  FWHM  =  10  nm) 


The  Bandpass  filter  is  a  series  of  substrates  with  material  designed  to  block  light  of  certain 
wavelengths.  Between  the  substrates  is  dielectric  material  with  specific  thickness  based  on  the 
wavelength  of  the  passthrough  along  with  spacer  layers.  The  Fabry-Perot  cavity  is  formed  by  the 
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layering  of  the  spacers  and  the  dielectric  material.  The  sandwiched  material  is  then  mounted  in  a 
protective  chassis.  See  Figure!. 


Incident  Light 


Anodized  AluminLim  Ring 


Substrates 
Dieletric  Stacks 

■  Absorption  Glass 

■  Epoxy  Layers 


Figure  23.  Schematic  of  a  typical  bandpass  fdter  (ThorLabs,  2013). 


The  Bandpass  filter  is  a  bidirectional  optical  component  with  two  optical  ports.  Optical 
signals  arriving  at  the  input  port  are  propagated  to  the  other  port  after  a  defined  propagation 
delay  and  the  filter  is  sensitive  to  the  power  of  the  optical  signals  that  are  propagated  through  the 
component.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold,  the  Bandpass  filter  may 
become  permanently  damaged  which  changes  its  propagation  characteristics.  Similarly,  the 
Bandpass  filter  is  sensitive  to  the  temperature  in  the  environment  in  which  it  operates.  If  the 
temperature  exceeds  defined  thresholds,  the  Bandpass  filter  may  become  temporarily  degraded 
or  permanently  damaged  which  changes  its  propagation  characteristics.  If  temporarily  degraded, 
the  device  may  recover  to  normal  operating  behavior  after  the  temperature  returns  to  a  “normal” 
operating  temperature. 

The  first  step  involved  with  the  modeling  the  Bandpass  filter  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica  software 
program  that  modeled  the  Bandpass  filter.  The  SME  developed  a  series  of  use  cases  that 
exercised  the  functionality  of  the  device  over  a  wide  variety  of  conditions  and  verified  the  model 
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and  validated  the  input  and  output  behavior  of  the  device  within  a  single  Mathematic  a  model 
(worksheet).  The  Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME 
communicated  the  behavior  of  the  Bandpass  filter  to  the  researcher.  Additional  information  came 
from  product  data  sheets  from  commercial  vendors  and  standard  texts  from  the  optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  Bandpass 
filter  using  the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated  to 
the  detailed  development  of  the  DEVS  model  of  the  Bandpass  fdter.  Once  developed,  the  model 
will  be  simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  in  the 
Mathematica  worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that 
the  DEVS  formal  model  matches  the  behavior  of  the  Mathematica  model  and  hence  the  real 
component. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that  created 
a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 


Figure  24.  Symbol  for  the  Bandpass  filter  in  the  QKD  system  architecture. 

D.2  Bandpass  filter  Conceptual  Model 
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Envin 


OptOut^L 

Figure  25.  Bandpass  filter  conceptual  model. 


Optlri]^ 


The  conceptual  model  for  a  Bandpass  filter  consists  of  two  optical  input  ports  {Optini,  OptIn2}, 
two  optical  output  ports  {OptOuti,  OptOut2},  and  one  environmental  input  port  {Evnin}.  The 
environmental  port  allows  external  sources  to  communicate  changes  in  the  operational 
environment  to  the  Bandpass  filter.  In  comparison  to  the  Bandpass  filter  symbol  used  in  the 
QKD  simulation  architecture  shown  in  Figure  3,  a  single  bidirectional  optical  connection  is 
decomposed  into  an  optical  input  and  an  optical  output  in  the  conceptual  model.  This  is 
necessary  to  properly  represent  the  behavior  of  the  device  using  the  DEVS  formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  Bandpass  filter,  a  small  portion  of  the  signal 
will  be  instantaneously  refiected  back  towards  the  signal  source.  Since  the  conceptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  4  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti. 

The  Bandpass  filter  calculates  the  power  of  the  incoming  packet  through  either  optical  port  after 
a  time  equaling  the  propagation  delay  of  the  module  at  full  power  minus  some  small  amount  to 
account  for  attenuation  through  the  device.  Even  though  the  bandpass  filter  is  meant  to  block 
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light  that  does  not  match  the  central  frequency,  a  small  amount  of  the  light  on  either  side  of  the 
central  frequency  will  make  it  through  the  device  and  out  the  input  port. 

The  Bandpass  filter  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation.  External  environmental  messages 
sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the  Bandpass  filter 
can  determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In 
either  case,  a  function  determines  how  the  propagation  changes  as  a  function  of  the  device  state 
and  current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation. 
This  greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat 
multiple  optical  signals  as  independent  entities. 

D.3  Mathematical  Model 

For  a  detailed  mathematical  description  of  the  Bandpass  filter,  refer  to  Section  2.8  which 
contains  the  Mathematica  worksheet  provided  by  the  optical  physics  SME. 

D.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
Bandpass  filter. 

When  an  optical  signal  arrives: 
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•  Calculate  the  optieal  power  of  the  signal.  If  the  optieal  power  exeeeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Place  the  optieal  paeket  into  the  queue 

•  Immediately  ealeulate  the  refieeted  power  of  the  signal  and  send  its  output  with  the  same 
port  number. 

•  Remove  the  paeket  from  the  queue,  ealeulate  the  attenuated  output  optieal  signal  based 
upon  the  input  optieal  signal,  the  OverPower  flag,  the  OverTemp  flag,  and  the  eurrent 
environment. 

•  Send  the  attenuated  output  signal  out  of  the  optieal  output  port  number  that  is  not  the 
same  as  the  input  port  number. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  eurrent  temperature  eontained  in  the  environmental 
message. 

•  If  the  current  temperature  exeeeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

D.5  Phase  Transition  Diagram 


The  phase  transition  diagram  in  Fig.  5  shows  the  phases  of  the  Bandpass  filter  in  the  boxes 
and  the  transitions  represented  by  arrows  between  the  phases.  Eaeh  transition  is  labeled  with  the 
type  of  transition  {dext  -  external  or  dint  -  internal)  and  the  signifieant  aetions  that  take  plaee 
during  the  transition.  Eaeh  arc  has  an  entry  either  beneath  or  beside  the  are  indieating  the  value 
of  the  time  advance  funetion  for  the  next  phase.  Eaeh  box  is  labeled  with  the  name  of  the  phase 
and  an  entry  showing  either  no  lambda  output  funetion  for  that  phase  or  what  the  phase  outputs. 
Note  there  is  a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the 
Bandpass  filter  at  the  same  time. 
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state  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn> 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  26.  Bandpass  filter  phase  transition  diagram. 

D.6  Event-Trace  Diagram 


This  seetion  shows  various  examples  of  paekets  entering  the  Bandpass  filter.  The  tables 
list  the  states  the  bandpass  filter  proeeeds  through  as  the  paekets  are  proeessed.  Eaeh  table  has 
the  state  number,  with  eaeh  state  eonsisting  of:  phase,  time  until  next  transition  (sigma),  store 
state  variable,  eurrent  temperature  of  the  Bandpass  filter,  the  over  temperature  flag  variable  and 
the  over  power  flag  variable.  The  next  eolumn  shows  the  eontents  of  the  queue  at  that  state,  the 
eontents  of  the  store  state  variable  and  any  notes. 


Explanations  for  eaeh  eolumn: 

•  Time:  elapsed  time  sinee  beginning  of  the  ease 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indieates  a  transitory  state 

•  Store:  eontents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  eurrent  internal  temperature.  In  this  ease,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 
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•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Queue:  eontents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 

D.  6.1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  10.  Case  I  state  list. 


Notes: 
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Figure  27.  Case  I  sequenee  diagram. 


D.  6,2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  1 1 .  Case  II  state  list. 


Notes: 

entry/  store  over  over  Interrupt  queue  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 
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Figure  28.  Case  II  sequence  diagram. 


D.6.3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 

Table  12.  Case  III  state  list . 
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Notes: 

entry/  store  over  over  interrupt  queue  assume 

time  state  exit  phase  sigma  (xi)  temp  temp  power  respond  (xi,tp)  tp=5 
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1  packet,  0  environmental  events,  2  external  events  (T=2  with  1  packet,  T=3  with  2  packets) 


Figure  29.  Case  III  sequence  diagram. 

D.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 

Table  13.  Case  IV state  list. 
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Figure  30.  Case  IV  sequence  diagram. 

D.  7  Bandpass  filter  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 
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•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 


For  the  Bandpass  filter  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  8ext,  8int,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp)  is  the  set  of  input  ports  and  values; 
Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp)  is  the  set  of  output  ports  and  values; 
S  =  set  of  sequential  states; 

Sext  =  2  X  XIj  ^  5*  is  the  external  state  transition  function; 

Sint  =  S'  ^  S'  is  the  internal  state  transition  function; 

Scon  =  2  X  S  is  the  confluent  transition  function; 

=  S  ^  T*  is  the  output  function; 
to  =  S  ^  U  00  or  S  ^  S  +  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xh  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  Bandpass  filter  (X/Vf?  Elft  S,  Sextt  Sint,  Scon,  1,  to) 
where 

tp  =  transmission  time  inside  the  attenuator 
temperature  =  current  temperature  of  the  attenuator 
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phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “reflect”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  optieal  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  current  optieal  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optieal  paeket 
messagebag=  variable  that  stores  the  eurrent  x  input  value(s)  (p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optical  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 
reflect  =  variable  that  stores  the  eurrent  reflected  optical  packet 
reflect.port  =  variable  that  holds  the  current  refleetion  output  port 
reflect.power  =  variable  that  holds  the  eurrent  reflection  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
queue.current  =  variable  that  holds  the  eurrently  seleeted  queue  event 
store  =  variable  that  holds  values  of  the  eurrent  optical  packet 
timcLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
e  =  elapsed  time  since  last  transition  oeeurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  seheduled  inputs 
queue  sizeO  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_refleeted()  =  method  returns  the  first  unrefieeted  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refiected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
insert_event_q()  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  eurrent  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
ealePeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optieal 
pulse 

caleAttenO  =  method  that  calculates  the  optical  packet  output  as:  f{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

ealeStrongO  =  method  that  ealculates  the  optical  packet  high  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

caleWeakO  =  method  that  calculates  the  optieal  paeket  low  power  output  as  fcurrenlv, 
temperature,  overtemp,  peakpwr,  overpwr)) 

ealoForwardO  =  method  that  ealeulates  the  optieal  paeket  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 
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calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  /[store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  /{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReflectedQ  =  method  that  calculates  reflection  power  of  an  optical  packet 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 

q-Vmm  =  minimum  value  in  the  queue 

v.q  =  value  from  a  queue  entry 

Every  Sext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Optini”,  “OptIn2”,  “Envin”}  with 

Xm  =  {(“Optini”,  Vopt),  (“OptIn2”,  Vopt),  (“Envin”,  Venv))  is  the  set  of  input  ports  and  values. 


OutPorts  =  {“OptOuti”,  “OptOut2”}  with 

Ym=  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  Yoptouti)}  is  the  set  of  output  ports  and  values. 

phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower  interruptRespond,  queue)  = 
{{“passive”,  “reflect”,  “respond”}  x  VxRx{“Y’\  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  F} 

External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((p;,v,), . . . . 

{pn,Vn)))  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  over  power, interrupt  Respond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  E  {‘‘Optlnf’,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_first(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd{queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “respond”  and  p  E  { “Optini  ”,  “OptIn2”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
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overpower  =  “Y” 
insert_event_q(cMrrenO 
remove_event_m(cMrrenO 
queue. current  =  queue_need_reflected() 
reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interrupt  Respond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interrupt  Respond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time_delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“refleef’,  0,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn)) 
if  phase  =  “refleet”  and  need.reflect  !=  null 
need.reflect  =  queue_need_reflected() 
current  =  need.reflect 

reflect  =  (current.p),  ealeRefleeted(cMrrent.v)) 
mark_refleeted(cMrrent) 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “refleet”  and  need.reflect  =  null 
need.re-flect  =  queue_need_refleoted() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
time. delay  =  current,  time,  delay 
if  InPort  =  “Optlm” 

outputPulse  =  oaloAtten(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
if  InPort  =  “OptIn2” 
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outputPulse  =  csi\cAiiQn{current.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
timeLeftRespond  =  propagation  delay 
else 

time. delay  =  timeLeftRespond 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time. delay  =  current.time. delay 
if  InPort  =  “Optini” 

outputPulse  =  calcAtten(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcAtten(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.xl.jcn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  dexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 
{reflect.p,  reflect. v) 
if  phase  =  “reflect” 

(output.port,  output.pulse) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 


Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  =  cr; 
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D.8  Mathematical  model 


Pulse  propagation  considerations  for  the  Bandpass  Filter  Module 
within  the  QKD  OMNet-F-l-  simulation  environment 


There  a  several  device  designs  which  can  achieve  bandpass  filtering  in  an  all-fiber  or  fiber-based  platform.  Chirped 
fiber  gratings,  tuned  acousio-optic  fiber,  and  imegraicd  miciXMipiic  devices  are  all  examples  fiber-based  bandpass 
filters.  More  research  needs  to  be  conducted  on  these  devices  to  form  a  physically  accurate  and  complete  naodcl.  In 
the  interest  of  expediting  the  construction  of  the  simulation  enviroment.  we  consider  here  die  basic  finctions  of  a  fiber- 
based  bandpass  filter.  The  bandpass  wavelength  region  will  be  considered  to  be  a  'tent-shaped",  with  roil-ofls  on 
either  side  of  the  central  wavelength,  finally  leveling  at  the  maximum  rejection  attenuation. 

The  opcratKinal  characteristics  arc  as  follous; 

-  light  input  to  port  I  will  exit  port  2 

-  light  input  to  port  2  will  exit  port  I 

The  only  s^ificant  modification  to  the  optical  mess^e  will  be  the  amplitude  (powerj.  dependent  upon  the  wavc- 
ki^th. 


Pulse  Characteristics  (e..x.) 

These  parameters  are  used  in  the  Jones  representation  of  the  standard  coherent  pulse  optical  message  packet. 

E, 


(Ex\  .  COSO 


Pertinent  Pulse  Characteristics  for  the  Bandpass  Filter  Module 

Kin  :•  Eo  (•  oloctxlc  flold  Input  into  poet  1  •) 

MO  :a  2  a  •  (2.99792458*10*)  /  (1.5482S*  10'*) 

(•  angular  fraquancy  of  optical  wavalangth,  units  of  Sad/ a  •) 

The  folowing  parameter  salnes  are  used  as  an  example,  and  are  taken  from  a  tunable  bandpass  fiber  optic 
filter  offered  by  neaport  optics  (http://aww.aea portxoin/Tunable-Bandpass-Fiber-<>ptic-Filter/835502/l033/fn- 
fo.aspx#tab_Overviea ). 

InaartlonLoaa  :■  l.S  (•  inaation  powar  loss  at  tba  banc^iass  wavalangth,  units  of  -dB  •) 
BandPassMavalangth  :■  1550*10'*  (*  cantral  wavalangth  of  bairdpass  window,  units  of  a  *) 


MidBandLoss  :■  0.5  (*  loss  in  addition  to  Infiandlosa, 

at  MidBandMidth  (*/-nm)  from  BandPassMavalangth  (nn)  ,  units  of  -dB  *) 
MidBancMidth  :•  1.0*10'*  (*  total  width  of  MidBandLoss  window,  units  of  a  *) 


OutBandloss  :■  20 

(*  powar  loss  outsida  of  tha  banc^xass  wavalangth  window,  units  of  -dB  *) 
OutBandHidth  :■  3.5*10'*  (*  total  width  of  bandpass  window,  units  of  a  *) 

Ratloss  :■  50  (*  typical  ratum  loss, 

signal  raflactad  by  an  input  baaa,  units  of  -dB  *) 

ToBgili  ;■  85  (*  aax  oparational  tasparatura,  units  of  ^  *) 

TsapL  ;■  15  (*  ain  oparational  tasparatura,  units  of  ^  *) 

MaxPwr  :■  500  (*  masiaua  oparational  powar,  units  of  bM  *) 
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Attenuation  Calculations  for  Bandpass  Filter 

Ain  :  ■  2  7T  *  ^2 . 997&245S  «■  /  uo  Inpul  irav>lBngth  cnlcrulatBa  frnai  glvan  wo 

MldfiandHidtli 

HadfiandLow  BandPassWavalangth  -  - 


Mi  dBu  dW  i  d  th 


Hidfi-andUigh  :  •  BAndPassHavalscLg-th  * 


OutfiandLcw  :  ■  bondPassWawlaxig^ 


Ou  tSaxidll  i  d  t2i 


OutfiandUigh  :•  fiacidfasaWaTTBlang^h  * 


Ou  tfi  asdW  i  d  th 


PiueJit  Cade:  if  Am  =  BandPassWaveIcngth, 

Eimt2[Ein_,  Tns«xtLonio5s_]|  •  Ein  .  ^  iQ-1—rtio-io../ia 

Piueda  Code:  cl.sc  if  Ain  >  BandPa&RWa^xilcngth  &&  Ain  s  MidBandHiglu 

£out2[Biii_«  Ii3Aa£'tionLoss_p  BaxidPas9Hav*IftrLgtdi_«  Mirffia  ndHidth_^  HidfiUindLoss_]  * 

Ein  .  'v/iQ-'“ti==i«./iD  ^ 

Q. 79432a  En 


Psuedo  Code;  else  if  .lin  <  BandPa:ssWa>x:]cDgth  &&  Wn  2  MidBandLow, 

£out2[Eii3  t  Is^ax-LiooLoss  ^  Aia  <  BandPaasHavsIangth  «  Mid&aiuiNidth  ,  MidBandLoss  ]  * 

Ein  .  1  O'  ( >* 

Psuedo  Code;  else  if  Ain  >  MidBandHigh  &&  .^in  s  OutBaadH  igh. 

£out2[Ein  «  IsautdociLoss  p  MidfiandLoss  ^  JLin  , 

MidBandHigh^,  Mi  rfftanrlT^a  OutBasdMigh_«  OutBaudLoas^]  ■ 

Pnuedo  Code;  else  if  Ain  <  MidBandLou'  &.&  Ain  z.  OutBandLow, 

£out2[Ein_«  Isjax'tiociLoss^,  HidBandLoaa_j  JU.n_, 

MidBandHigh^,  Hi^dBaiidLaa  0utBai3dHigl]_«  OutBandLciaa^]  • 

Ein*  1/ 10"' 

Psuedo  Code:  else, 

Eout2[Ein_,  lna»itionLo53_,  OutEnxidLo»_]  •  Ein  *  V  *  a/  10-^“"“”^*^“ 


■  Ttl  SOiM  ■ /*  1 D 


*  V 


LO 


Hi  ^lwaJT«ay  /lQ 


*  ‘ij  10  f 


*■  [QnfimJUarE-M’.i^ifidlMB)  /'ID 


If  wc  Hish  to  flag  the  aiienuator  to  include  undesired  return  (reflected)  messages,  the  following  oftcialians  would 
bold  true. 
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£oLitl[Eiiil_,  ft*tLo53_]  :«  Einl  * 

Eaut2[Ein2_,  E*tLoas_]  :*  Eiii2  t 
CDT^i  WcIhlIl'  nules: 

hAtp:y/'wvi-w.ncwpurt.4:4xnrrLjniibk'-Buo(J|M^Mt'4H.'T<^}pbL:'hlljciy^3^5U2/l033/mru.xipx 
hltp://'www.iifwlechffiubipL'^L'XKnLaiWbarKl_p9iK_lilljer.lriml 
hitp  J/'A'Vii'Mi‘.d|Ta:^bijC4j«un.i;m>^iciJtluL‘t_(li.'l2iiLpbp?id*'l  TV 
hltp://www'.i$ouUliLi.L'uiiu'h]glu!«)|jibunrMdiTi  {*  W4lni  emailin’  *] 

LiiS  raitmL  No.  Bl  i*  Ttnuiui^luncd  iiLuidSu-oplM:  binx^KU^  riJE4.T  *) 


D.9  Component  Use  Cases 

D.9.1  Respond  to  an  Optical  Packet  in  the  Bandpass  filter 

Optical  packet  arrives  at  the  bandpass  filter.  A  portion  of  optieal  packet  reflects  back  down 
incoming  optical  line.  Plaee  the  optieal  paeket  into  the  optieal  queue.  Cheek  to  see  if  optieal 
paeket  overpowers  the  bandpass  filter.  Reeords  overpower  eondition,  if  applieable.  Remove  the 
optical  packet  from  the  queue  and  caleulate  the  attenuated  optieal  output  signal  based  on  the 
input  signal  frequeney,  the  bandpass  eentral  frequeney  and  the  current  component  state. 
Propagate  the  attenuated  optieal  output  signal  out  of  the  component  optieal  port  that  is  not  the 
same  as  the  input  port. 


•  Identified  Alternative  Uses  Cases 

o  React  to  an  environmental  message 

•  Assumptions 

o  Component  has  completed  initialization  sequenee  at  least  onee 
o  Refleetions  are  not  affeeted  by  component  state 
o  Ineoming  eleetrical  signals  are  not  affeeted  by  component  state 
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Initialization 

No  Optical  Output 


ormal  Stal 

pected  Optic 

L 

Output 

Under  degraded 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


Degraded  State 

Reduced  Optical 
Output 


Over  damaged 
temperature  or 
power  threshold 


Damaged  State 

No  Optical  Output 


Over  damaged 
temperature  or 
power  threshold 


•Reflections  are  not  configured  to  be  effected  by  state 
•Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  31.  Component  states. 


state  =  {phase,  o,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  32.  Bandpass  phase  transition  diagram. 

D.  9.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  reflected  properly. 

•  Optical  packet  entered  and  removed  from  queue  in  proper  sequence. 

•  Overpower  condition  properly  recognized  and  recorded. 
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•  Optical  packet  attenuated  properly  to  the  limit  of  accuracy. 

•  Optical  packet  propagated  out  the  correet  port  at  the  correct  time. 

D.9.3  Respond  to  an  Environmental  Packet  in  the  Bandpass  filter 

Environmental  packet  arrives  at  the  bandpass  filter.  Check  to  see  if  environmental  packet 
temperature  sets  the  eomponent  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level 
returns  eomponent  from  degraded  state  to  normal  state.  Records  change  in  condition,  if 
applicable.  Change  component  function  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

D.  9. 4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  reeeived  properly 

•  Overtemperature  eondition  properly  recognized  and  reeorded 

•  Change  of  state  completed  and  recorded  properly,  if  neeessary 

•  Change  component  function  properly,  if  neeessary 

D.IO  Component  Test  Cases 

Each  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  eheek  behavior  and  timing.  Each  component  had 
eaeh  of  its  input  ports  (optieal,  environmental  (env),  and/or  control  (ctrl))  tested  singly,  then  in 
different  eombinations  of  ports  and  input  messages.  All  identified  errors  were  corrected  and  the 
eomponent  retested  until  it  funetioned  properly  for  eaeh  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  eomponent  is  interrupted  during  message  proeessing. 
Control  messages  work  in  the  same  way,  but  foree  the  component  to  begin  behavior  to  react  to 
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the  contents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 

Table  5.  Bandpass  Test  Cases. 


Phase 

Case 

Inject  Port 

Optl  Opt2 

Env 

Note 

Running  Totals 
opt  #  env  # 

Passive 

1 

1 

0 

0 

single 

1 

0 

2 

0 

1 

0 

single 

2 

0 

3 

0 

0 

1 

single 

2 

1 

4 

1 

1 

0 

same  time 

4 

1 

5 

1 

1 

0 

differ  time 

6 

1 

6 

1 

1 

1 

same  time 

8 

2 

7 

1 

1 

1 

differ  time 

10 

3 

8 

0 

1 

1 

same  time 

11 

4 

9 

0 

1 

1 

differ  time 

12 

5 

10 

1 

0 

1 

same  time 

13 

6 

11 

1 

0 

1 

differ  time 

14 

7 

20 

2 

0 

0 

same  time 

16 

7 

21 

0 

2 

0 

same  time 

18 

7 

22 

2 

2 

0 

same  time 

22 

7 

23 

2 

2 

0 

differ  time 

26 

7 

24 

2 

2 

1 

same  time 

30 

8 

25 

2 

2 

1 

differ  time 

34 

9 
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26 

0 

2 

1 

same  time 

36 

10 

27 

0 

2 

1 

differ  time 

38 

11 

28 

2 

0 

1 

same  time 

40 

12 

29 

2 

0 

1 

differ  time 

42 

13 

totals 

21 

21 

13 

42 

Respond 

41 

2 

0 

0 

single 

44 

13 

42 

0 

2 

0 

single 

46 

13 

43 

1 

0 

1 

single 

47 

14 

44 

2 

1 

0 

same  time 

50 

14 

45 

2 

1 

0 

differ  time 

53 

14 

46 

2 

1 

1 

same  time 

56 

15 

47 

2 

1 

1 

differ  time 

59 

16 

48 

0 

2 

1 

same  time 

61 

17 

49 

0 

2 

1 

differ  time 

63 

18 

50 

2 

0 

1 

same  time 

65 

19 

51 

2 

0 

1 

differ  time 

67 

20 

60 

3 

0 

0 

same  time 

70 

20 

61 

0 

3 

0 

same  time 

73 

20 

62 

3 

2 

0 

same  time 

78 

20 

63 

3 

2 

0 

differ  time 

83 

20 

64 

3 

2 

1 

same  time 

88 

21 

65 

3 

2 

1 

differ  time 

93 

22 

66 

0 

3 

1 

same  time 

96 

23 

67 

0 

3 

1 

differ  time 

99 

24 

68 

3 

0 

1 

same  time 

102 

25 

69 

3 

0 

1 

differ  time 

105 

26 

totals 

36 

27 

13 

63 

TCI 

1 

0 

2 

single 

106 

28 

TC2 

1 

0 

2 

single 

107 

30 

TC3 

1 

0 

2 

single 

108 

32 

TC4 

1 

0 

2 

single 

109 

34 

totals 

4 

0 

8 

12 
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Appendix  E  -  Beamsplitter 


E.l  Device  Description: 

The  beamsplitter  is  an  optical  device  used  to  split  a  beam  of  light  in  to  a  reflected  beam 
and  a  transmitted  beam  and  can  be  used  to  combine  two  beams  of  light  into  one  stream  (Saleh  & 
Teich,  1991).  In  practical  terms,  light  from  one  input  fiber  is  sent  through  a  collimating  lens,  then 
divided  by  the  beamsplitter  optic  and  focused  on  the  output  ports.  Different  fibers  can  be  used  on 
each  port  and  different  types  of  beamsplitting  material  can  be  used  inside  the  housing. 

A  beamsplitter  can  be  made  from  housing  with  collimating  lenses  and  some  form  of  a 
beamsplitting  material,  such  as  a  partially  reflective  mirror  or  a  think  glass  plate,  which  splits  the 
light  (Saleh  &  Teich,  1991).  Physical  designs  include  cubes  mounted  into  brackets  for  free-space 
optics  and  housings  that  have  permanently  mounted  pigtails  or  connectors  for  fiber  lines  and 
pure  fiber  devices  commonly  known  as  couplers.  The  amount  of  light  directed  to  each  port  is 
variable  and  determined  by  the  material  inside  the  beamsplitter.  Many  combinations  of  splitting 
ratios  exist,  some  of  the  most  common  are  50:50,  90:10,  70:30,  but  the  devices  can  be  made  with 
almost  any  ratio.  See  Figure  1  for  an  example  of  a  four-port  free-space  beamsplitter. 


Figure  33.  View  of  a  free-space  beamsplitter  with  fiber  inputs  (OZOptics,  2013). 
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Although  beamsplitters  may  have  from  three  to  eight  or  more  ports,  this  researeh  will  use 
the  four  port  beamsplitting  deviees  with  fiber  pigtails,  per  the  discussion  with  the  SME.  In  this 
research,  the  beamsplitter  is  a  bidirectional  optical  component  with  four  optical  ports.  Light 
entering  the  primary  port  splits  into  two  beams  and  exits  through  the  two  output  ports  with  the 
splitting  ratio  dependent  on  the  device.  In  the  opposite  direction,  the  component  works  the  same 
way,  splitting  the  light  by  passing  through  a  portion  of  the  beam  and  reflecting  the  rest  to  the  port 
opposite  the  reflected  port  used  by  the  primary  path. 

The  light  suffers  a  slight  attenuation  from  the  material  as  it  passes  through  the  device  and 
the  splitting  medium  has  a  phase  effect  for  the  reflected  portion  of  the  beam.  The  reflected  beam 
undergoes  a  global  phase  shift  of  nil  and  is  applied  to  light  passing  through  the  device  in  both 
directions. 

The  internal  material  is  sensitive  to  the  power  of  the  optical  signals  that  are  propagated 
through  the  component.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold,  the 
beamsplitter  may  become  permanently  damaged  which  changes  its  propagation  characteristics. 
Similarly,  the  beamsplitter  is  sensitive  to  the  temperature  in  the  environment  in  which  it  operates. 
If  the  temperature  exceeds  defined  thresholds,  the  beamsplitter  may  become  temporarily 
degraded  or  permanently  damaged  which  changes  its  propagation  characteristics.  If  temporarily 
degraded,  the  device  may  recover  to  normal  operating  behavior  after  the  temperature  returns  to  a 
“normal”  operating  temperature. 

The  first  step  involved  with  the  modeling  the  beamsplitter  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica  software 
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program  that  modeled  the  beamsplitter.  The  SME  developed  a  series  of  use  cases  that  exercised 
the  functionality  of  the  device  over  a  wide  variety  of  conditions  and  verified  the  model  and 
validated  the  input  and  output  behavior  of  the  device  within  a  single  Mathematica  model 
(worksheet).  The  Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME 
communicated  the  behavior  of  the  beamsplitter  to  the  researcher.  Additional  information  came 
from  product  data  sheets  from  commercial  vendors  and  standard  texts  from  the  optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the 
beamsplitter  using  the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is 
dedicated  to  the  detailed  development  of  the  DEVS  model  of  the  beamsplitter.  Once  developed, 
the  model  will  be  simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  in  the 
Mathematica  worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that 
the  DEVS  formal  model  matches  the  behavior  of  the  Mathematica  model  and  hence  the  real 
component. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 


3 

Figure  34.  Symbol  for  the  4-port  beamsplitter  in  the  QKD  system  architecture. 
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E.2  Beamsplitter  Conceptual  Model 


Envin 

i 

▼ 

Optln2 

OptOut2 

Optlrii 

1 

Beamsplitter 

OptOut 

OptOuti 

Optln4 

Optln3 

1 

▼ 

OptOut3 

Figure  35.  Beamsplitter  eoneeptual  model. 

The  eoneeptual  model  for  a  beamsplitter  eonsists  of  four  optieal  input  ports  {Optini, 
OptIn2,  Optins,  OptIn4},  four  optieal  output  ports  {OptOuti,  OptOut2,  OptOuts,  OptOut4},  and 
one  environmental  input  port  {Evnin}.  The  environmental  port  allows  external  sourees  to 
eommunieate  ehanges  in  the  operational  environment  to  the  beamsplitter.  In  eomparison  to  the 
beamsplitter  symbol  used  in  the  QKD  simulation  arehiteeture  shown  in  Figure  2,  a  single 
bidireetional  optieal  eonneetion  is  deeomposed  into  an  optieal  input  and  an  optieal  output  in  the 
eoneeptual  model.  This  is  neeessary  to  properly  represent  the  behavior  of  the  deviee  using  the 
DEVS  formalism. 

When  an  optieal  signal  is  sent  to  the  input  of  the  beamsplitter,  a  small  portion  of  the 
signal  will  be  instantaneously  refleeted  baek  to  the  signal  souree.  Sinee  the  eoneeptual  model 
deeomposes  eaeh  bidireetional  eonneetion  to  a  diserete  unidireetional  output  input  and  a  diserete 
unidireetional  optieal  output,  this  means  that  an  optieal  signal  arriving  at  Optini  in  Fig.  3  will 
instantaneously  generate  a  refleeted  emitting  out  of  OptOuti. 
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The  beamsplitter  ealeulates  ehanges  to  the  power  (attenuation)  of  any  paeket  eoming 
through  an  optieal  port  after  a  time  equaling  the  propagation  delay  of  the  module.  The  packet  is 
calculated  at  full  power  minus  some  small  amount  to  account  for  attenuation  through  the  device. 
The  model  splits  each  incoming  optical  packet  into  a  ‘passed’  packet  and  a  ‘reflected’  packet, 
with  the  strength  of  each  packet  determined  by  the  beamsplitting  ratio,  and  injecting  these 
packets  into  the  queue.  Each  of  these  entries  are  a  (port,  value)  pair,  just  as  any  other  entry  into 
the  queue,  with  the  [port]  entry  equal  to  the  output  port  and  the  [value]  equal  to  the  adjusted 
values  of  the  incoming  packet.  Additionally,  packets  output  on  the  reflected  port  rotate  %I2  (i.e.  a 
=  a  +  7i/2)  due  to  the  effects  of  the  beamsplitting  material  inside  the  device  and  is  applied  by  the 
‘passed’  and  ‘reflected’  functions. 

The  beamsplitter  calculates  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation.  External  environmental  messages 
sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the  beamsplitter 
can  determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In 
either  case,  a  function  determines  how  the  propagation  changes  as  a  function  of  the  device  state 
and  current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation.  This 
greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 
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E.3  Mathematical  Model 


For  a  detailed  mathematieal  description  of  the  beamsplitter,  refer  to  Section  3.8  which 
contains  the  Mathematica  worksheet  provided  by  the  optical  physics  SME. 

E.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
beamsplitter. 


•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Determine  the  input  port  number. 

•  Immediately  calculate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same 
port  number. 

•  Remove  the  packet  from  the  queue  and  split  it  into  two  packets 

•  Update  the  values  for  one  packet  as  a  ‘passed’  optical  signal  based  on  the  characteristics 
of  the  beamsplitter,  the  original  values  of  the  input  optical  signal  and  the  current 
environment  and  set  the  correct  output  port. 

•  Update  the  values  for  the  other  packet  as  a  ‘reflected’  optical  signal  based  on  the 
characteristics  of  the  beamsplitter,  the  original  values  of  the  input  optical  signal  and  the 
current  environment  and  set  the  correct  output  port. 

•  Send  the  attenuated  output  signal  out  of  the  optical  output  port  number  that  is  not  the 
same  as  the  input  port  number. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 
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•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

E.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  beamsplitter  in  the  boxes  and 
the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled  with  the  type 
of  transition  (dext  -  external  or  dint  -  internal)  and  the  significant  actions  that  take  place  during  the 
transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value  of  the  time 
advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase  and  an  entry 
showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs.  Note  there  is 
a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the  beamsplitter  at 
the  same  time. 

state  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  36.  beamsplitter  phase  transition  diagram. 

E.6  Event-Trace  Diagram 
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This  section  shows  various  examples  of  packets  entering  the  beamsplitter.  The  tables  list 
the  states  the  beamsplitter  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  beamsplitter,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes. 

Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Queue:  contents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 

E.  6. 1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  14.  Case  I  state  list. 


Notes: 

entry/  store  over  over  interrupt  queue  assume 


time 

state 

1-packet 

exit 

no  env 

phase 

no  ext 

sigma 

0  Ctrl 

(X/) 

temp 

temp 

power 

respond 

(x/,  tp) 

tp=5 

0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

n 

(xE5) 

0 

si 

entry 

reflect 

0 

null 
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n 

n 

n 

(xE5) 

0 

si 

exit 

reflect 

5 

xl 

c 

n 

n 

n 

null 

0 

s2 

entry 

respond 
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xl 

c 

n 

n 

n 

null 

5 

s2 

exit 

respond 

inf 

xl 
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n 

n 

n 

null 

5 

s3 

entry 

passive 

inf 

xl 

c 

n 

n 

n 

null 
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1  packet,  0  environmental  events,  0  external  events 


I  '  I 

Figure  3  7.  Case  I  sequence  diagram. 

E.  6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  15.  Case  II state  list. 

Notes: 

entry/  store  over  over  Interrupt  queue  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 


1-packet  0  env  1  opt  0  Ctrl 


0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

n 

null 

0 

sO 

exit 

passive 
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1  packet,  0  environmental  events,  1  external  event  (with  1  packet)  at  e=2 
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Figure  38.  Case  II  sequence  diagram. 


E.6.3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 

Table  16.  Case  III  state  list . 

Notes: 
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1  packet,  0  environmental  events,  2  external  events  (T=2  with  1  packet,  T=3  with  2  packets) 


Figure  39.  Case  III  sequence  diagram. 

E.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 

Table  17.  Case  IV state  list. 
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Figure  40.  Case  IV  sequence  diagram. 

E.  7  Beamsplitter  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 
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•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptResond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 


For  the  beamsplitter  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  dext,  Smt,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp]  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

dext  =  2  X  XIj  ^  5*  is  the  external  state  transition  function; 

Sint  =  S'  ^  S'  is  the  internal  state  transition  function; 

Scon  =  0  X  XIp  — S  is  the  confluent  transition  function; 

=  S  ^  T*  is  the  output  function; 
to  =  S  ^  U  00  or  S  ^  R  +  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  to}^)}  is  the  total  set  of  states; 

Xh  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  beamsplitter  {Xmi  Yjyf,  Sextt  Sinti  Scotty  tO) 

where 

tp  =  transmission  time  inside  the  attenuator 
temperature  =  current  temperature  of  the  attenuator 

phase  ~  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “reflect”,  “respond”} 
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overtemp  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  optieal  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  eurrent  optical  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optical  packet 
messagebag=  variable  that  stores  the  current  x  input  value(s)  (p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optical  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 
reflect  =  variable  that  stores  the  current  reflected  optical  packet 
reflect.port  ~  variable  that  holds  the  current  reflection  output  port 
reflect.power  =  variable  that  holds  the  current  reflection  power 
time,  delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
queue.current  =  variable  that  holds  the  currently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
e  =  elapsed  time  since  last  transition  occurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  scheduled  inputs 
queue_size()  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_first()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_reflected()  =  method  returns  the  first  unreflected  queue  event 
messagebag_tirst()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_reflected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update_delay()  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
insert_event_q()  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  f{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcHigh()  =  method  that  calculates  the  passed  optical  packet  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcLowO  =  method  that  calculates  the  reflected  optical  packet  low  power  output  as 
ficurrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  forward  direction  optical  packet  output  as:  fstore, 
temperature,  overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  backward  direction  optical  packet  output  as: 
fistore,  temperature,  overtemp,  peakpwr,  overpwr) 
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calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  ficurrent.v,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReflectedQ  =  method  that  calculates  reflection  power  of  an  optical  packet 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 

q.Vmm  =  minimum  value  in  the  queue 

v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Optini”,  “OptIn2”,  “Optlnj”,  “OptIn4”,  “Envin”}  with 
Xm  =  {(“Optlm”,  Vopt),  (“OptIn2”,  Vopt),  (“OptIn3”,  Vopt),  (“OptIn4”,  Vopd,  (“Envin”,  is 

the  set  of  input  ports  and  values. 

OutPorts  =  {“OptOuti”,  “OptOut2”,  “OptOut3”,  “OptOut4”}  with 
Ym  =  {(“OptOuti”,  YoptOutl),  (“OptOut2”,  YoptOutl),  (“OptOut3”,  YoptOuts),  (“OptOut4”,  YoptOut4)} 
is  the  set  of  output  ports  and  values. 

phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower  interruptRespond,  queue)  = 
{{“passive”,  “reflect”,  “respond”}  x  ExRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  V) 

External  Transition  Function: 

dextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((p;,v,), . . . . 

{pn,Vn)))  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  queue.x\..xn) 
if  phase  =  “passive”  and  p  E  {“Optini”,  “OptIn2”,  “OptIn3”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrre«t) 
queue.current  =  queue_first(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond ,  queue.x\..xn) 
if  phase  =  “respond”  and  p  E  {“Optlnf’,  “OptIn2”,  “OptInS”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
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current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrenO 
remove_event_m(cMrren^) 
queue. current  =  queue_need_reflected() 
reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  —  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time_delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

(phase,  a-e,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn) 
otherwise; 

Internal  Transition  Function: 

Sint(phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“refleet”,  0,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn)) 
if  phase  =  “refleet”  and  need.reflect  !=  null 
need.reflect  =  queue_need_reflected() 
current  =  need.reflect 

reflect  =  (current.p),  ealeRefleeted(cMrrent.v)) 
mark_reflected(cMrrent) 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “refleet”  and  need.reflect  =  null 
need.reflect  =  queue_need_refleoted() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
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time.delay  =  current.time. delay 

if  current.p  =  “Optini”  /*  input  port  1  -  strong  4  weak  3  */ 

newl  =  (“0pt0ut3”,ealeHigh(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
new2  =  (“OptOut4”,calcLow(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
else 

if  current.p  =  “Optini”  /*  input  port  2  -  strong  3  weak  4  */ 

newl  =  (“0pt0ut4”,caleHigh(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“OptOut3”,calcLow(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

else 

if  current.p  =  “0ptln3”  /*  input  port  3  -  strong  2  weak  1  */ 

newl  =  (“OptOuti”,calcHigh(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“OptOut2”,caleLow(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
else  /*  input  port  4  -  strong  1  weak  2*/ 

newl  =  (“0pt0ut2”,caleHigh(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“OptOuti”,caleLow(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
timeLeftRespond  =  propagation  delay 
else 

time.delay  =  timeLeftRespond 

(“respond”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  eurrent.time. delay 

if  current.p  =  “Optini”  /*  input  port  1  -  strong  4  weak  3  */ 

newl  =  (“0pt0ut3”,calcHigh(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“OptOut4”,calcLow(cMrrent.v,  temperature,  over  temp,  peakpwr,  overpwr)) 
else 

if  current.p  =  “0ptln2”  /*  input  port  2  -  strong  3  weak  4  */ 

newl  =  (“0pt0ut4”,calcHigh(cMrrent.v,  temperature,  over  temp,  peakpwr,  overpwr)) 
newl  =  (“OptOut3”,caleLow(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

else 

if  current.p  =  “0ptln3”  /*  input  port  3  -  strong  2  weak  1  */ 

newl  =  (“OptOuti”,calcHigh(cMrrent.v,  temperature,  over  temp,  peakpwr,  overpwr)) 
newl  =  (“OptOut2”,calcLow(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
else  /*  input  port  4  -  strong  1  strong  2*/ 

newl  =  (“0pt0ut2”,calcHigh(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“OptOuti”,calcLow(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.xl.jcn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 
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Confluence  Function: 


Scon(s,  ta(s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower)  = 

{reflect p,  reflect. v) 
if  phase  =  “reflect” 

(newl.p,  newl.v) 
if  phase  =  “respond” 

{newl.p,  newl.v) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

ta{phase,  a,  store,  temperature,  overtemp,  overpower)  =  cr; 
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E.8  Mathematical  model 


Pulse  propagation  considerations  for  the  Beam  Splitter  Module  within 
the  QKD  OMNet'*^*  simulation  environment 


This  module  is  conlatos  iniofmatian  pertaining  lo  disc-tapcrcd  fiber  couplers.  This  moduk-  does  not  conlain  informa- 
Ikin  ter  polarizing  beam  splitters.  Please  sec  ibe  polarizing  beam  spliiicr  module  math  package  Tor  that  inrormation. 
Physics 

c  :■  2. 99792159  *  lO'  (■*  sp«B{l  of  zd/s 


Pulse  Charaeicristics  {c.g.) 

These  paramciers  are  used  in  Ihc  janes  leprcscniation  of  the  standard  eohetcnl  pul.se  optical  message  packet. 
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a  :m  rr  /  i  (*  polarization,  xMasurad  from  tha  x^axisj 
is  j-Tri  m  casa;  posibiva  diagonal  *) 

^  :■  0  (-ft  linaar  polarization  in  tKa  peuiti'w  diagonal#) 


Splitter  Charactcristk  (modeled  upon  50/50  beam  Rplitler.  Simply  modiry  HOP  to  99  cr  90  far99/L  and  9CVID  beam 
spIiiicrsK  respectively) 

ELO-P  :■  50  {#  hj.gh  output  parcanbaga  (a.g.  50^  *) 

LOP  :■  10Q*IIOP(*  lev  output  paxcantaga  «) 

CxcasaLoas  :■  0.2 

(*  poaar  drop  (laas)  bayond  tha  axpactad  splitting  xatlD,  units  of  dfi  t) 
bibjcP&Lx  0.2  (*  Maximum  polarization  depandant  loss  in  tha  x  axis,  units  of  dB#) 

HaxPPLy  :■  0.2{*  Maximua  polaricabion  dapandant  loss  in  tha  y  axis,  units  of  dfi  *) 

PPLx  :■  fiancloiiiPaal[{0,  MaxPCLx)) 

(*  salacbs  a  valua  balov  MaxPOLx  at  random.  This  should  ha  callad  ocica 
during  a  sliulaticn  and  bald  constant  for  tha  duration  of  that  run  «) 

PDLy  :■  E%andiaiiiReal[{D^  MaxPOLy) )  (#  salants  a  valua  balov 
HaxPDLy  at  random.  This  should  be  callad  onca  during  a 
simulation  and  hald  constant  for  tha  duration  of  that  run  *) 

Pcoplial  :•  500*  10'*^  («  propagation  dalay, 

assuming  -IQon  baamsplittar  langth,  units  of  saconds#) 

Beam  Splitter  Calculations 


The  firsl  order  of  business  is  to  sepajB.te  the  polsrization  slalc  into  its  respective  onhogoiml  cempionciits. 

Ejc  :«  An^  «  Cos  [a]  projactlon  of  eb«  KlHzeric  fiald  anplxtuda  i.n  elia  X  ili.r>ction  -t) 

£y  :•  AlI^»  *  Sin  [a]  (t  projaction  of  tlu  KlKtric  flald  asplltud*  in  tha  ¥  dlrKtion  «) 

Again,  for  Ibis  example,  we  are  considering  a  5D/50  beamsplitter  (HOP  =  50). 

The  standard  rom  for  ihe  conversion  matrix,  give  a  2x2  (Itvo  input,  two  output)  bcamspbiier,  assuming  no  coupling 
between  pdarizabons,  is  a.s  follows: 
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VIjOP  i  Vhop  D  0 

i  VttOP  VloF  D  0 

0  Q  VLOP  i  VhOP 

0  a  i  VhiOp  VlOP  , 

uliiMie  the  matiix  M  acts  upon  the  input  {pons  1  £.  3]  elcclric  field  values  In  yield  the  electric  fields  fbf  the  outpuLs 
(ports  5  &  4).  If  we  assume  that  we  have  an  inpul  on  port  1,  leaving  E2x  and  E2y  lo  be  zero,  we  have; 

£lx  ;•  Ex 
ELy  :•  Ey 


1 

M  ;■  — 
110 


'  E3x 

Elx  ' 

Eix 

•  H. 

E2x 

E3y 

Ely 

1  E*y , 

/  .  E2x  t  0  /  .  E2y  0 


AmpCoi(a]  , 

vT  ^ 


1  Amp  Cos  [*^]  1  I  [*^]  1  r  ^  Amp  Sin[o] 

^  -v'T 


VT  ^  Vl 


J' 


)1 


We  must  new  include  loss.  As  loss  is  given  in  dB  with  reialkin  to  power,  and  we  ate  dealing  with  the  electric  field 
lure,  some  conversion  is  necessary. 


E3xFin  •  E3x  * 


E4xFin 


E4 


J  /  ML* 

x*'Jlo  ^  *  ■u  iD"“ir 


Q.47B531  £d 


Q. 484021  i  £d 


E3yFin  •  E3y  * 


E4yFin  «  E4y* 


t/ 


10 


a.4aD859£D 


0.484632  i  £d 


To  caleiilale  the  electric  field  amplitude  of  the  outpul  pulses  we  need  lo  lake  die  vector  sum 
E30ut  ■  'ij ESxFin^  ♦  E3yFin^  /  f  FullEinplify 
0.67 8393 

E*Out  ■  -^EixFiji^  ♦  E4yri.n^  /f  PullSiaplify 
0.684941  ,/-Eo^ 

Note  the  negative  above  in  the  Eo.  This  is  accounted  ibr  by  altering  the  global  pha.se  {^)  of  Ihc  output  pulse  at  port  4 
byJi/2. 

*3  :•  0 

**  jt  /2 

We  also  need  to  keep  track  of  the  output  polanzattoitl  s>. 
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a3  ■  ArcTmj)[E3yFlii  /  E3xFin] 
at  m  ArcTai}[E4yFiji  /  E4xFin] 

0.787824 

0.786029 

Ouput  Pulse  Considerations 


Wc  now  need  to  use  the  calculated  values  to  create  the  output  pulses.  In  this  case,  we  have  a  pulse  coming  out  of  Port 
3  and  Port  4. 

The  pulse  coming  out  of  port  3  will  use  E3()uL  a3,  and  43 


E3(t)=  [  j  =«<f)E30ut 

\2 

E4(t)=  [  I  =K<f)E40ut 

=  g(t)-£2- 


coso3 
(sin  o3)e^*^ 

(i/vT 

1/V2 

cosa4  \ 


(sma4)r^^  ) 

,/vT  I 

./VT,= 


Compilable  version  is  below 
E3[t_]  •gtt]  E30ut  «*•*•*• 


/  Co» [03]  \ 

lsin[a3]  J 


1^0.478531  e*””*-’®"*'’**  ,£0'  git]}.  |o .  480859  ****  ® 


E4[t_] 


■  g[t]  E40ut •*“*«*• 


Coa [a4]  \ 

Sin[a4]  ) 


,  Eo’ 


9lt]}} 


||0. 484021  V-Eo^  g[t]},  }o .  484632  i  c‘**”‘“‘*‘*  ‘  -E«>^ 


Additional  Considerations  -  Reverse  Direction  (input) 


Note  that  the  beamsplitter  performs  a  unitar>'  transformation  upon  the  input  fields.  Thus,  the  reserse  direction  (pulse 
input  into  Ports  3  or  4]  is  handled  identically  to  the  forward-fed  direction; 


Elx 

E2x 

1 

Ely 

IS 

• 

.E2y 

i  VaoF  0 


0  i  VhoF 


E3z 
E4x 
E3y 
U4y  j 


E.9  Component  Use  Cases 


E.9.1  Respond  to  an  Optical  Packet  in  the  Beamsplitter 
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Optical  packet  arrives  at  beamsplitter.  A  portion  of  optical  packet  reflects  back  down 
incoming  optical  line.  Place  the  optical  packet  into  the  optical  queue.  Check  to  see  if  optical 
packet  overpowers  the  beamsplitter.  Records  overpower  condition,  if  applicable.  Remove  the 
optical  packet  from  the  queue  and  split  the  packet  into  transmitted  and  reflected  packets. 
Calculate  the  attenuated  optical  output  signals  based  on  the  input  signal,  the  input  optical  port 
and  the  eurrent  component  state.  Propagate  the  attenuated  optical  output  signal  out  of  the 
component  optical  port  based  on  the  input  port. 

•  Identified  Alternative  Uses  Cases 

o  React  to  an  environmental  message 

•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
o  Reflections  are  not  affected  by  component  state 
o  Incoming  electrical  signals  are  not  affected  by  component  state 


Under  d 
tempera 
power  tl 


'Reflections  are  not  configured  to  be  effected  by  state 
'Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  41.  Component  states. 
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state  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  42.  Beamsplitter  phase  transition  diagram. 

E.9.2  End  Goals 

•  Optieal  paeket  refleeted  properly. 

•  Optical  packet  entered  and  removed  from  queue  in  proper  sequence. 

•  Overpower  condition  properly  recognized  and  recorded. 

•  Optical  packet  attenuated  properly  to  the  limit  of  accuracy. 

•  Optical  packet  propagated  out  the  correct  port  at  the  correct  time. 

E.9.3  Respond  to  an  Environmental  Packet  in  the  Beamsplitter 

Environmental  packet  arrives  at  the  beamsplitter.  Check  to  see  if  environmental  packet 
temperature  sets  the  component  to  degraded  or  damaged  state.  Check  to  see  if  temperature  level 
returns  component  from  degraded  state  to  normal  state.  Records  change  in  condition,  if 
applicable.  Change  component  function  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

E.  9. 4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 
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•  Overtemperature  eondition  properly  reeognized  and  reeorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

E.IO  Beamsplitter  Test  Cases 

Each  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  check  behavior  and  timing.  Each  component  had 
each  of  its  input  ports  (optical,  environmental  (env),  and/or  control  (ctrl))  tested  singly,  then  in 
different  combinations  of  ports  and  input  messages.  All  identified  errors  were  corrected  and  the 
component  retested  until  it  functioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  processing. 
Control  messages  work  in  the  same  way,  but  force  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
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SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 

Table  5.  Beamsplitter  Test  Cases. 


Running 

Inject  Port 

Totals 

Phase 

Case 

Optl 

Opt2 

Opts 

Opt4 

Env 

Notes 

opt  # 

env  # 

Passive 

1 

1 

0 

0 

0 

0 

single 

1 

0 

2 

0 

1 

0 

0 

0 

single 

2 

0 

3 

0 

0 

1 

0 

0 

single 

3 

0 

4 

0 

0 

0 

1 

0 

single 

4 

0 

5 

0 

0 

0 

0 

1 

single 

4 

1 

6 

1 

1 

1 

1 

0 

same  time 

8 

1 

7 

1 

1 

1 

1 

0 

differ  time 

12 

1 

8 

1 

1 

1 

1 

1 

same  time 

16 

2 

9 

1 

1 

1 

1 

1 

differ  time 

20 

3 

10 

0 

1 

0 

0 

1 

same  time 

21 

4 

11 

0 

1 

0 

0 

1 

differ  time 

22 

5 

12 

1 

0 

0 

0 

1 

same  time 

23 

6 

13 

1 

0 

0 

0 

1 

differ  time 

24 

7 

14 

0 

0 

1 

0 

1 

same  time 

25 

8 

15 

0 

0 

1 

0 

1 

differ  time 

26 

9 

16 

0 

0 

0 

1 

1 

same  time 

27 

10 

17 

0 

0 

0 

1 

1 

differ  time 

28 

11 

20 

2 

0 

0 

0 

0 

same  time 

30 

11 

21 

0 

2 

0 

0 

0 

same  time 

32 

11 

22 

0 

0 

2 

0 

0 

same  time 

34 

11 

23 

0 

0 

0 

2 

0 

same  time 

36 

11 

24 

2 

2 

2 

2 

0 

same  time 

44 

11 

25 

2 

2 

2 

2 

0 

differ  time 

52 

11 

26 

2 

2 

2 

2 

1 

same  time 

60 

12 

27 

2 

2 

2 

2 

1 

differ  time 

68 

13 

28 

0 

2 

0 

0 

1 

same  time 

70 

14 

29 

0 

2 

0 

0 

1 

differ  time 

72 

15 

30 

2 

0 

0 

0 

1 

same  time 

74 

16 

31 

2 

0 

0 

0 

1 

differ  time 

76 

17 

32 

0 

0 

2 

0 

1 

same  time 

78 

18 

33 

0 

0 

2 

0 

1 

differ  time 

80 

19 

34 

0 

0 

0 

2 

1 

same  time 

82 

20 

35 

0 

0 

0 

2 

1 

differ  time 

84 

21 

totals 

21 

21 

21 

21 

21 

84 

Respond 

41 

2 

0 

0 

0 

0 

single 

86 

21 

214 


42 

0 

2 

0 

0 

0 

single 

88 

21 

43 

0 

0 

2 

0 

0 

single 

90 

21 

44 

0 

0 

0 

2 

0 

single 

92 

21 

45 

1 

0 

0 

0 

1 

single 

93 

22 

46 

2 

1 

1 

1 

0 

same  time 

98 

22 

47 

2 

1 

1 

1 

0 

differ  time 

103 

22 

48 

2 

1 

1 

1 

1 

same  time 

108 

23 

49 

2 

1 

1 

1 

1 

differ  time 

113 

24 

50 

0 

2 

0 

0 

1 

same  time 

115 

25 

51 

0 

2 

0 

0 

1 

differ  time 

117 

26 

52 

2 

0 

0 

0 

1 

same  time 

119 

27 

53 

2 

0 

0 

0 

1 

differ  time 

121 

28 

54 

0 

0 

2 

0 

1 

same  time 

123 

29 

55 

0 

0 

2 

0 

1 

differ  time 

125 

30 

56 

0 

0 

0 

2 

1 

same  time 

127 

31 

57 

0 

0 

0 

2 

1 

differ  time 

129 

32 

60 

3 

0 

0 

0 

0 

same  time 

132 

32 

61 

0 

3 

0 

0 

0 

same  time 

135 

32 

62 

0 

0 

3 

0 

0 

same  time 

138 

32 

63 

0 

0 

0 

3 

0 

same  time 

141 

32 

64 

3 

2 

2 

2 

0 

same  time 

150 

32 

65 

3 

2 

2 

2 

0 

differ  time 

159 

32 

66 

3 

2 

2 

2 

1 

same  time 

168 

33 

67 

3 

2 

2 

2 

1 

differ  time 

177 

34 

68 

0 

3 

0 

0 

1 

same  time 

180 

35 

69 

0 

3 

0 

0 

1 

differ  time 

183 

36 

70 

3 

0 

0 

0 

1 

same  time 

186 

37 

71 

3 

0 

0 

0 

1 

differ  time 

189 

38 

72 

0 

0 

3 

0 

1 

same  time 

192 

39 

73 

0 

0 

3 

0 

1 

differ  time 

195 

40 

74 

0 

0 

0 

3 

1 

same  time 

198 

41 

75 

0 

0 

0 

3 

1 

differ  time 

201 

42 

totals 

36 

27 

27 

27 

21 

117 

TCI 

1 

0 

0 

0 

2 

single 

202 

44 

TC2 

1 

0 

0 

0 

2 

single 

203 

46 

TC3 

1 

0 

0 

0 

2 

single 

204 

48 

TC4 

1 

0 

0 

0 

2 

single 

205 

50 

TC5 

1 

0 

0 

0 

2 

single 

206 

52 

TC6 

1 

0 

0 

0 

2 

single 

207 

54 

totals 

6 

0 

0 

0 

12 

6 
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Appendix  F  -  Circulator 


F.l  Device  Description: 

The  circulator  is  an  optical  device  allows  light  to  pass  through  in  one  direction.  Light 
entering  port  one  exits  port  two  with  minimal  attenuation  but  is  highly  attenuated  leaving  port 
three.  Light  entering  port  two  exits  port  three  with  minimal  attenuation  and  is  highly  attenuated 
leaving  port  one.  A  “full”  circulator  allows  light  to  enter  port  three  and  pass  on  to  port  one  with 
minimal  attenuation  but  heavily  attenuating  port  two.  A  “quasi”  circulator  highly  attenuates  any 
light  entering  port  three  at  ports  one  and  two.  Circulators  are  used  in  multiplexers,  bi-directional 
pumps  and  chromatic  dispersion  compensation  devices  (ThorLabs,  2013).  See  Figure  1  for  an 
example  of  a  quasi-circulator. 


Port  2 


Figure  43.  View  of  a  three  port  circulator  (ThorLabs,  2013). 

A  quasi-circulator  can  be  made  from  a  polarizing  beam  splitter,  a  Faraday  rotator  and  a 
half-wave  plate  in  line.  Any  light  travelling  in  the  forward  direction  through  the  circulator  has  its 
polarization  changed  by  90°  as  it  passes  through  the  Faraday  rotator  and  half-wave  plate.  This 
allows  for  light  to  pass  from  port  one  to  port  two  and  from  port  two  to  port  three.  Light  from  port 
three  to  port  one  is  directed  into  the  circulator  housing  by  the  polarizing  beam  splitter.  Any  light 
travelling  backwards  through  the  ports  is  rotated  then  directed  to  the  housing  by  the  polarizing 
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beam  splitter,  but  some  light  does  leak  out  the  ineorreet  ports.  For  a  four-port  device,  the  Faraday 
rotator  and  half-wave  plate  are  sandwiched  between  two  polarizing  beam  splitters. 

Circulators  are  non-reciprocal  optical  devices  because  the  changes  to  the  properties  of 
light  are  not  reversed  by  travelling  backwards  through  the  device  (Saleh  &  Teich,  1991). 
Although  there  are  polarization-independent  and  polarization-dependent  types  of  circulators,  this 
research  will  consider  the  polarization-independent  version  only,  as  the  polarization  dependent 
version  is  used  in  highly  limited  applications  (per  conversation  with  SME).  The  model  developed 
here  will  be  for  the  full-circulator,  although  quasi-circulators  are  more  commonly  used,  as  the 
full-circulator  is  the  more  general  model. 

The  Circulator  is  a  bidirectional  optical  component  with  three  optical  ports.  Optical 
signals  arriving  at  the  input  port  are  propagated  to  next  port  in  sequence  after  a  defined 
propagation  delay  and  the  polarizing  material  is  sensitive  to  the  power  of  the  optical  signals  that 
are  propagated  through  the  component.  If  the  optical  power  of  a  pulse  exceeds  a  defined 
threshold,  the  Circulator  may  become  permanently  damaged  which  changes  its  propagation 
characteristics.  Similarly,  the  Circulator  is  sensitive  to  the  temperature  in  the  environment  in 
which  it  operates.  If  the  temperature  exceeds  defined  thresholds,  the  Circulator  may  become 
temporarily  degraded  or  permanently  damaged  which  changes  its  propagation  characteristics.  If 
temporarily  degraded,  the  device  may  recover  to  normal  operating  behavior  after  the  temperature 
returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  the  modeling  the  Circulator  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica  software 
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program  that  modeled  the  Circulator.  The  SME  developed  a  series  of  use  cases  that  exercised  the 
functionality  of  the  device  over  a  wide  variety  of  conditions  and  verified  the  model  and  validated 
the  input  and  output  behavior  of  the  device  within  a  single  Mathematica  model  (worksheet).  The 
Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME  communicated  the 
behavior  of  the  Circulator  to  the  researcher.  Additional  information  came  from  product  data 
sheets  from  commercial  vendors  and  standard  texts  from  the  optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  Circulator 
using  the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated  to  the 
detailed  development  of  the  DEVS  model  of  the  Circulator.  Once  developed,  the  model  will  be 
simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  in  the  Mathematica 
worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that  the  DEVS 
formal  model  matches  the  behavior  of  the  Mathematica  model  and  hence  the  real  component. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 


Figure  44.  Symbol  for  the  3-port  typical  circulator  in  the  QKD  system  architecture. 

F.2  Circulator  Conceptual  Model 
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OptOut2 


OptOuti 

OptOut3 

Figure  45.  Circulator  conceptual  model. 


The  eonceptual  model  for  a  Cireulator  eonsists  of  three  optieal  input  ports  {Optini, 
Optini,  OptIn3},  three  optieal  output  ports  {OptOuti,  OptOut2,  OptOut2},  and  one  environmental 
input  port  {Evnin} .  The  environmental  port  allows  external  sourees  to  eommunieate  changes  in 
the  operational  environment  to  the  Circulator.  In  comparison  to  the  Circulator  symbol  used  in  the 
QKD  simulation  architeeture  shown  in  Figure  2,  a  single  bidireetional  optieal  eonneetion  is 
deeomposed  into  an  optical  input  and  an  optical  output  in  the  coneeptual  model.  This  is 
neeessary  to  properly  represent  the  behavior  of  the  deviee  using  the  DEVS  formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  Circulator,  a  small  portion  of  the  signal 
will  be  instantaneously  refleeted  baek  to  the  signal  souree.  Sinee  the  eonceptual  model 
deeomposes  each  bidirectional  connection  to  a  discrete  unidireetional  output  input  and  a  diserete 
unidireetional  optical  output,  this  means  that  an  optieal  signal  arriving  at  Optini  in  Fig.  3  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti. 

The  Circulator  calculates  ehanges  to  the  power  (attenuation)  and  polarization  of  any 
paeket  eoming  through  an  optieal  port  after  a  time  equaling  the  propagation  delay  of  the  module. 
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The  packet  is  calculated  at  full  power  minus  some  small  amount  to  account  for  attenuation 
through  the  device  if  passing  through  to  the  correct  port  or  heavily  attenuated  if  passing  to  an 
incorrect  port  (for  example,  passing  from  port  three  to  port  one  in  a  quasi-circulator).  The  model 
handles  this  undesired  throughput  by  splitting  each  incoming  optical  packet  into  a  ‘strong’ 
packet  (one  that  is  output  through  the  correct  port)  and  a  ‘weak’  packet  (one  that  is  output 
through  the  incorrect  port)  and  injecting  these  packets  into  the  queue.  Each  of  these  entries  are  a 
(port,  value)  pair,  just  as  any  other  entry  into  the  queue.  Additionally,  every  packet  is  rotated  by 
90°  due  to  the  effects  of  the  Faraday  rotator  and  half-wave  plate  as  it  passes  through  the  device 
and  this  effect  is  applied  by  the  ‘strong’  and  ‘weak’  functions. 

The  Circulator  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation.  External  environmental  messages 
sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the  Circulator  can 
determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In  either 
case,  a  function  determines  how  the  propagation  changes  as  a  function  of  the  device  state  and 
current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation.  This 
greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 
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F.3  Mathematical  Model 


For  a  detailed  mathematieal  deseription  of  the  Cireulator,  refer  to  Seetion  4.8  which  contains 
the  Mathematica  worksheet  provided  by  the  optical  physics  SME. 

F.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
Circulator. 


•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Determine  the  input  port  number. 

•  Immediately  calculate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same 
port  number. 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Split  the  incoming  optical  packet  into  two  entries  in  the  queue. 

•  Update  the  values  for  one  queue  entry  as  a  ‘strong’  optical  signal  based  on  the 
characteristics  of  the  circulator,  the  original  values  of  the  input  optical  signal  and  the 
current  environment  and  set  the  correct  output  port. 

•  Update  the  values  for  the  other  queue  entry  as  a  ‘weak’  optical  signal  based  on  the 
characteristics  of  the  circulator,  the  original  values  of  the  input  optical  signal  and  the 
current  environment  and  set  the  correct  output  port. 

•  After  the  propagation  time  has  elapsed,  send  the  output  signal  out  of  the  optical  output 
port. 
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When  an  environmental  message  arrives; 


•  Update  the  Current! emp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

F.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  Circulator  in  the  boxes 
and  the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled  with  the 
type  of  transition  {Aext  -  external  or  Am  —  internal)  and  the  significant  actions  that  take  place 
during  the  transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value 
of  the  time  advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase 
and  an  entry  showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs. 
Note  there  is  a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the 
Circulator  at  the  same  time. 

state  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  46.  Circulator  phase  transition  diagram. 
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F.  6  Event-Trace  Diagram 


This  section  shows  various  examples  of  packets  entering  the  Circulator.  The  tables  list 
the  states  the  circulator  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  Circulator,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes. 


Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Queue:  contents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 


F.  6. 1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  18.  Case  I  state  list. 


Notes: 
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5  I  s3 _ I  entry  |  passive  |  inf  |  xl  |  c  |  n  |  n _ In _ |  null 


1  packet,  0  environmental  events,  0  external  events 


I 

Figure  4  7.  Case  I  sequence  diagram. 


F.  6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  19.  Case  II  state  list. 

Notes: 

entry/  store  over  over  Interrupt  queue  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 
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Figure  48.  Case  II  sequence  diagram. 


F.6.3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 

Table  20.  Case  III  state  list. 

Notes: 

entry/  store  over  over  interrupt  queue  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 
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Figure  49.  Case  III  sequence  diagram. 

F.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 


Table  21 .  Case  IV  state  list. 
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Figure  50.  Case  IV  sequence  diagram. 

F.  7  Circulator  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 
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•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 


For  the  Circulator  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  dext,  Smt,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp}  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  2  X  Xh  ^  S'  is  the  external  state  transition  function; 

Sint  =  S  ^  S  is  the  internal  state  transition  function; 

Scon  =  2  X  ^  S  is  the  confluent  transition  function; 

/I  =  S  — T*  is  the  output  function; 

ta  =  S  ^  Rn  U  cc  ov  S  ^  R  ^  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  Circulator  (Xv/?  Ev/j  S,  Sgxt',  Sint^  Scon,  to) 
where 

tp  =  transmission  time  inside  the  attenuator 

temperature  =  current  temperature  of  the  attenuator 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 

phase  =  {“passive”,  “reflect”,  “respond”} 
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overtemp  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  optieal  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  eurrent  optical  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optical  packet 
messagebag=  variable  that  stores  the  current  x  input  value(s)  (p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optical  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 
reflect  =  variable  that  stores  the  current  reflected  optical  packet 
reflect.port  ~  variable  that  holds  the  current  reflection  output  port 
reflect.power  =  variable  that  holds  the  current  reflection  power 
time,  delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
newl=  variable  to  hold  1®'  output  values 
new2  =  variable  to  hold  output  values 

queue.current  =  variable  that  holds  the  currently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
e  =  elapsed  time  since  last  transition  occurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  scheduled  inputs 
queue  sizeO  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_reflected()  =  method  returns  the  first  unrefiected  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refiected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
insert_event_q()  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  f{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 
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calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  /[store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  /{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReflectedQ  =  method  that  calculates  reflection  power  of  an  optical  packet 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 

q-Vmm  =  minimum  value  in  the  queue 

v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Optini”,  “OptIn2”,  “Optlnj”,  “Envin”}  with 
Xm  =  {(“Optini”,  Vopt),  (“OptIn2”,  Vopt),  (“OptIn3”,  Vopt),  (“Envin”,  Venv))  is  the  set  of  input 
ports  and  values. 

OutPorts  =  {“OptOuti”,  “OptOut2”,  “OptOuta”}  with 
Ym  =  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  Yoptouti),  (“OptOuts”,  Yoptouts))  is  the  set  of  output 
ports  and  values. 

phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 
{{“passive”,  “reflect”,  “respond”}  x  ExRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  V) 


External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((p;,v,), . . . . 

{pn,Vn)))  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.xl ..xn) 

if  phase  =  “passive”  and  p  G  {“Optlnf’,  “OptIn2”,  “OptIn3”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_first(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd{queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 
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(“reflect”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond ,queue.x\..xn) 
if  phase  =  “respond”  and  p  E  {“Optini”,  “OptIn2”,  “OptInS”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue. current  =  queue_need_reflected() 
reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.xl.jcn) 
if  phase  =  “passive”  and  p  —  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time_delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

(phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn) 
otherwise; 

Internal  Transition  Function: 

di„t(phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“reflect”,  0,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn)) 
if  phase  =  “reflect”  and  need.reflect  !=  null 
need.reflect  =  queue_need_reflected() 
current  =  need.reflect 

reflect  =  (current.p),  calcReflected(cMrrent.v)) 
mark_reflected(cMrrent) 

(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
queue. x\..xn) 
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if  phase  =  “reflect”  and  need.reflect  =  null 
need.reflect  =  queue_need_reflected() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
time.delay  =  current.time. delay 

if  current. p  =  “Optlnf’  /*  input  port  1  -  strong  2  weak  3  */ 

newl  =  (“OptOut2”,calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

new2  =  (“0pt0ut3”,calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

else 

if  current.p  =  “0ptln2”  /*  input  port  2  -  strong  3  weak  1  */ 

newl  =  (“OptOut3”,calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
new2  =  (“OptOutl”,calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
else  /*  input  port  3  -  strong  1  weak  2*/ 

newl  =  (“OptOutl”,calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
new2  =  (“0pt0ut2”,calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
timeLeftRespond  =  propagation  delay 
else 

time.delay  =  timeLeftRespond 

(“respond”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  current.time. delay 

if  current.p  =  “Optini”  /*  input  port  1  -  strong  2  weak  3  */ 

newl  =  (“OptOut2”,calcStrong(cMrre«t.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

new2  =  (“0pt0ut3”,calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

else 

if  current.p  =  “Optini”  /*  input  port  2  -  strong  3  weak  1  */ 

newl  =  (“OptOut3”,calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
new2  =  (“OptOutl”,calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
else  /*  input  port  3  -  strong  1  weak  2*/ 

newl  =  (“OptOutl”,calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
new2  =  (“0pt0ut2”,calcWeak  {current.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.xl.jcn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  dexiSintis),  0,  x); 
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Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue) 

{reflect. p,  reflect. v) 
if  phase  =  “reflect” 

(newl.p,  newl.v) 
if  phase  =  “respond” 

{newl.p,  newl.v) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

ta{phase,  a,  store,  temperature,  overtemp,  overpower)  =  cr; 
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F.8  Mathematical  model 


Pulse  propagation  considerations  for  the  Circulator  Module  within  the 
QKD  OMNet++  simulation  environment 

For  lliis  module  I  will  coosidcr  only  the  polarization  htdepcndeni  typcoFcivculalar.  Polarizatian-dcpcndcnt  circulalan; 
da  exist,  but  are  used  in  highly  limited  applkations. 

The  operational  chaiaetcrtstics  ate  as  TdIIows: 

-  light  input  to  port  1  will  cxil  port  2 

-  light  input  to  port  1  will  exil  port  J 

-  light  input  to  port  3  will  be  highly  allenuatcd  (zero  amplitude  passed) 

These  ciieulalan:  coiirorm  la  what  is  Itnown  as  a  'quasi-eireulator'  and  arc  sufTicient  tor  most  applications.  "Full- 
ekreulators'',  which  output  htam  port  I  li^t  input  to  port  3,  da  exist,  but  are  not  otticn  used. 

Pulse  Characteristics  (e-xd 

These  parameters  are  u.sed  in  the  janes  leptrcsenlation  of  the  standard  eohcrcnl  pulse  optical  message  packeL 

«'>-l 

Pertinent  Pulse  Characterisrics  for  the  Circulator  Module 

£inl  :•  Eol  («  slBctxic  fi«ld  Input  into  port  1  *) 

£in2  :  •  Eo2  «lKtxic  f ittLd  input:  ioto  port  2 
Ein3  :■  Ea3  («  alsctric  £i«ld  input  into  port  3 

Inputfoll  :■  al  (■*  polArization  of  optica.1  flnld  input  to  port  1 

li]putPDl2  :p  a2  (■*  polArization  of  optiezL  flzld  input  to  port  2 

Inputfoll  :■  a3  (■#  polzrization  of  optical  flald  input  to  port  3 

The  follawin^  piarameter  values  are  examples  of  tvpical  fiber-based  circulaloFS  and  are  taken  from  COTS 
devices  ofTcred  by  the  (lOuld  corporation  (www.Eouldfoxom) 
lusartLoas  :«-0.S  issaxtion  loss., 

loss  in  poucF  dii«  to  tranaKiasion  through  davic*  {i.a.  1^2, 2^3),  units  of  -effl  *} 

RatLosa  :■  50  («  ratum  LosSr  signal  raflactad  by  an  input  baam.^  units  of  -dB  *) 

:«  70  (*  maz  cparational  taaoparaturaj  unita  of  ■*) 

:a  D  (■*  adn  ^>arational  tanparatura,  units  of  ^  *■) 

MaxRwr  :•  500  maximum  opaxational  powar.  units  of  mH  «■) 

lao  40  (-ft  iaolation  in  unita  of  -dfi.  If  wa  wish  to  conaidar  it 

(flag?)  thia  ia  tha  mriziTimm  powr  that  will  axit  from  an  undaairad  port, 
i.a.  input  on  port  1.  oul^njt  on  port  3 

PIC  19  0.Q5  («  mazifiTum  polarization  moda  disparaion  dua  to  davica.^ 
units  of  picoaaconda.  won't  ba  considarad  in  thia  varaion 

Altenuation  Calculalions  for  Circulator 

The  power  out,  given  parameters  in  the  dB  regime,  is  calculated  as, 

l>out[Pin_,  rna«rtLDa3_]  ;  •  Pin  » 

Again,  we  t>'pically  deal  with  the  optical  pulse  mathematics  in  lenns  of  the  declrie  field.  In  that  case,  the  proper 
operations  are. 
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(•  casa:  opti.cal  input  on  port  1  •) 


Koot2(Bxnl_.  lns«rtIoBS_]  :•  linl  *  V 

Eout3[Kin2_,  InMrtIosa_]  :•  Ein2  •  >/ 10'*"**“*"'**  (*  casa:  optical  input  on  port  2  •) 
Bout2[Kln3_,  lnaartLoaa_]  :a  BxnJaO.O  (•  caaa:  optical  input  on  port  3  •) 

If  wc  wish  to  flag  the  circulator  to  include  undesired  port  throughput,  the  following  operations  would  hold  true. 
Bout3(Binl_.  Ibo_)  :•  Binl  *  V 

(•  caaa:  optical  input  on  port  1,  undaairad  ouQmt  port  3  •) 

Boutl  (Bin2_,  lao_)  :  ■  Ein2  *  V 10**^“' 

(•  caaa:  optical  input  on  port  2,  undaairad  output  port  1  •) 

Boot2(Bin3_.  Iao_)  :•  Bin3  •  V  10-^'‘® 

(•  caaa:  optical  input  on  port  3,  undaairad  output  port  2  •) 

Boutl [Bin3_,  Iao_]  :• 

Bin3*  y/ 10'‘*“'*®  (•  caaa:  optical  input  on  port  2,  undaairad  output  port  1  •) 

If  wc  wish  to  flag  the  circulator  to  include  undesired  return  (reflected)  ntcss^cs.  the  following  operabons  would 
hold  tnic. 

Boutl  [Binl_,  Ratlo8a_]  :  ■  Binl  * 

Bout2  (Bin2_.  ltatIoaa_]  :  ■  Bin2  *  V 

Boot3  [Bin3_.  llatLoaa_]  :  ■  Bin3  *  yj  lo*"*"-**^ 

Polarizaion  Calculations 

Due  to  the  naluie/function  of  a  polarization  independent  flber-based  circulator,  the  beam  polarization  is  rotated  by  90* 
in  from  port  I  to  port  2.  and  again  from  port  2  to  port  3.  This  rotation  is  in  the  same  'direction'',  regardless  of  which 
path  ( l->2. 2->3)  the  light  takes. 

IT 

OotputPol2[InputPoll  ]  :  ■  InputPoll  - — 

“  2 

n 

0utputPol3[InputPol2  ]  :■  InpotPol2  - — 

“  2 
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F.9  Component  Use  Cases 


F.9.1  Respond  to  an  Optical  Packet  in  the  Circulator 

Optical  packet  arrives  at  the  circulator.  A  portion  of  optical  packet  refleets  back  down 
incoming  optical  line.  Place  the  optieal  packet  into  the  optical  queue.  Check  to  see  if  optieal 
paeket  overpowers  the  circulator.  Records  overpower  condition,  if  applicable.  Remove  the 
optical  packet  from  the  queue  and  split  the  optical  packet  into  strong  and  weak  pulse  paekets. 
Caleulate  the  attenuated  optical  output  signal  based  on  the  input  signal,  the  strength  of  the  packet 
and  the  current  eomponent  state.  Propagate  the  attenuated  optical  output  signal  out  of  the 
component  optical  port  based  on  the  input  port  and  component  design. 


•  Identified  Alternative  Uses  Cases 

o  React  to  an  environmental  message 

•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
o  Reflections  are  not  affeeted  by  component  state 
o  Incoming  electrical  signals  are  not  affected  by  component  state 
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Initialization 

No  Optical  Output 


ormal  Stal 

pected  Optic 

L 

Output 

Under  degraded 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


Degraded  State 

Reduced  Optical 
Output 


Over  damaged 
temperature  or 
power  threshold 


Damaged  State 

No  Optical  Output 


Over  damaged 
temperature  or 
power  threshold 


•Reflections  are  not  configured  to  be  effected  by  state 
•Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  51.  Component  states. 


State  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


ta=  time 
delay 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  52.  Circulator  phase  transition  diagram. 

F.  9.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  reflected  properly. 

•  Optical  packet  entered  and  removed  from  queue  in  proper  sequence. 

•  Overpower  condition  properly  recognized  and  reeorded. 

•  Optical  packet  attenuated  properly  to  the  limit  of  accuraey. 
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•  Optical  packets  propagated  out  the  correet  ports  at  the  correet  time. 

F.9.3  Respond  to  an  Environmental  Packet  in  the  Circulator 

Environmental  packet  arrives  at  the  circulator.  Check  to  see  if  environmental  paeket  temperature 
sets  the  component  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level  returns 
component  from  degraded  state  to  normal  state.  Reeords  ehange  in  condition,  if  applicable. 
Change  eomponent  function  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

F.  9. 4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  reeeived  properly. 

•  Overtemperature  eondition  properly  reeognized  and  reeorded. 

•  Change  of  state  completed  and  reeorded  properly,  if  neeessary. 

•  Change  eomponent  function  properly,  if  neeessary. 

F.IO  Circulator  Test  Cases 

Eaeh  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  cheek  behavior  and  timing.  Eaeh  component  had 
each  of  its  input  ports  (optical,  environmental  (env),  and/or  eontrol  (ctrl))  tested  singly,  then  in 
different  eombinations  of  ports  and  input  messages.  All  identified  errors  were  eorrected  and  the 
eomponent  retested  until  it  functioned  properly  for  eaeh  test  ease. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  eomponent  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  proeessing. 
Control  messages  work  in  the  same  way,  but  foree  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  foree  an  immediate  response  to  the  change 
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in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 

Table  5.  Circulator  Test  Cases. 


Phase 

Case 

Inject  Port 

Optl  Opt2  Opts 

Env 

Notes 

Running  Totals 
opt  #  env  # 

Passive 

1 

1 

0 

0 

0 

single 

1 

0 

2 

0 

1 

0 

0 

single 

2 

0 

3 

0 

0 

1 

0 

single 

3 

0 

4 

0 

0 

0 

1 

single 

3 

1 

5 

1 

1 

1 

0 

same  time 

6 

1 

6 

1 

1 

1 

0 

differ  time 

9 

1 

7 

1 

1 

1 

1 

same  time 

12 

2 

8 

1 

1 

1 

1 

differ  time 

15 

3 

9 

0 

1 

0 

1 

same  time 

16 

4 

10 

0 

1 

0 

1 

differ  time 

17 

5 

11 

1 

0 

0 

1 

same  time 

18 

6 

12 

1 

0 

0 

1 

differ  time 

19 

7 

13 

0 

0 

1 

1 

same  time 

20 

8 

14 

0 

0 

1 

1 

differ  time 

21 

9 

20 

2 

0 

0 

0 

same  time 

23 

9 

21 

0 

2 

0 

0 

same  time 

25 

9 

22 

0 

0 

2 

0 

same  time 

27 

9 

23 

2 

2 

2 

0 

same  time 

33 

9 

24 

2 

2 

2 

0 

differ  time 

39 

9 
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25 

2 

2 

2 

1 

same  time 

45 

10 

26 

2 

2 

2 

1 

differ  time 

51 

11 

27 

0 

2 

0 

1 

same  time 

53 

12 

28 

0 

2 

0 

1 

differ  time 

55 

13 

29 

2 

0 

0 

1 

same  time 

57 

14 

30 

2 

0 

0 

1 

differ  time 

59 

15 

31 

0 

0 

2 

1 

same  time 

61 

16 

32 

0 

0 

2 

1 

differ  time 

63 

17 

totals 

21 

21 

21 

17 

63 

Respond 

41 

2 

0 

0 

0 

single 

65 

17 

42 

0 

2 

0 

0 

single 

67 

17 

43 

0 

0 

2 

0 

single 

69 

17 

44 

1 

0 

0 

1 

single 

70 

18 

45 

2 

1 

1 

0 

same  time 

74 

18 

46 

2 

1 

1 
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Appendix  G  -  Optical  Photodiode  (Classical  Detector) 


G.l  Device  Description 

The  classical  detector  used  in  Quantum  Key  Distribution  (QKD)  systems  is  an  optical 
photodiode  used  as  a  photodetector.  These  devices  rely  on  photogenerated  charge  carriers  to 
create  a  response  when  encountering  photons.  A  photodiode  is  a  p-n  junction  whose  current 
increases  when  it  absorbs  photons.  The  photons  become  absorbed  in  the  depletion  layer  between 
the  p  and  n  layers,  causing  a  current  to  flow  between  the  two  (Saleh  &  Teich,  1991).  This  current 
is  linearly  proportional  to  the  amount  of  received  photons  and  can  be  measured  by  standard 
electrical  detectors. 

Photodiodes  used  as  detectors  are  usually  of  the  p-i-n  construction,  where  a  layer  of 
lightly  doped  semiconductor  material  is  inserted  between  the  p  and  n  layers.  The  inserted  layers 
increase  the  depletion  layer,  increasing  the  surface  area  for  capturing  photons  and  reducing 
response  time  See  Figure  1  for  examples  of  photodiodes  (Saleh  &  Teich,  1991). 


Figure  53.  Example  of  photodiodes  (ThorLabs,  2013). 

Photodectectors  are  made  from  many  materials  that  depend  on  the  qualities  desired  in  the 

device.  Materials  for  high-speed  detectors  include  silicon,  gallium  phosphide,  and  indium 
gallium  arsenide.  Many  of  these  devices  have  a  low  dark  current  count  (current  caused  by 
environment  rather  than  the  measured  photons)  but  have  a  high  cost  for  telecommunication 
optical  fiber  frequencies.  See  Table  1  for  photodiode  general  characteristics. 
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Table  22. 


Table  of  photodiode  characteristics  (ThorLabs,  2013). 


Material 

Sensitivit 

Dark  Current  Speed  Cost 

Silicon  (Si) 

Low 

High  Speed  400  -  1000  nm  Low 

Germanium  (Ge) 

High 

Low  Speed  900  -  1600  nm  Low 

Gallium  Phosphide  (GaP) 

Low 

High  Speed  150  -  550  nm  Moderate 

Indium  Gallium  Arsenide  (luGaAs) 

Low 

High  Speed  800  -  1800  nm  Moderate 

Indium  Arsenide  Antimonide  (InAsSb) 

High 

Low  Speed  1000  -  5800  umHigh 

Extended  Range  Indium  Gallium  Arsenide  (InGaAs)  High 

High  Speed  1200  -  2600  umHigh 

Mercury  Cadmium  Telluride  (MCT,  HgCdTe) 

High 

Low  Speed  2000  -  5400  umHigh 

The  photodiode  is  a  unidirectional  optical  component  with  one  optical  port  and  one 
electrical  control  port.  The  optical  port  is  the  input  port  for  the  optical  packets  with  the  only 
output  being  reflected  signals.  Optical  signals  arriving  at  the  optical  port  are  reflected  back  down 
the  optical  path  after  suffering  an  amount  of  attenuation.  All  received  optical  packets  generate  an 
electrical  signal,  but  the  signal  must  exceed  a  threshold  detection  level  before  the  device  signals 
the  high-level  controllers.  Once  an  optical  packet  exceeds  the  threshold,  the  photodiode 
generates  a  message  to  its  controller  with  a  power  level  linearly  proportionate  to  the  incoming 
power  level.  The  InGAs-type  of  p-i-n  photodiode  used  in  telecommunication  wavelengths  has  a 
response  time  of  approximately  66000ps  (ThorLabs,  2013). 

The  photodiode  is  sensitive  to  the  power  of  the  optical  signals  that  are  received  by  the 
component.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold,  the  photodiode  may 
become  permanently  damaged  which  changes  its  attenuation  and  output  characteristics. 
Similarly,  the  photodiode  is  sensitive  to  the  temperature  in  the  environment  in  which  it  operates. 
If  the  temperature  exceeds  defined  thresholds,  the  photodiode  may  become  temporarily  degraded 
or  permanently  damaged  which  changes  its  attenuation  and  output  characteristics.  If  temporarily 
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degraded,  the  device  may  recover  to  normal  operating  behavior  after  the  temperature  returns  to  a 
“normal”  operating  temperature. 

The  first  step  involved  with  the  modeling  the  photodiode  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  series  of  use  cases  that  exercised  the  functionality  of  the  device  over  a 
wide  variety  of  conditions  and  verified  the  model  and  validated  the  input  and  output  behavior  of 
the  device.  Additional  information  came  from  product  data  sheets  from  commercial  vendors  and 
standard  texts  from  the  optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the 
photodiode  using  the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is 
dedicated  to  the  detailed  development  of  the  DEVS  model  of  the  photodiode.  Once  developed, 
the  model  will  be  simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  by 
the  SME.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that  the  DEVS 
formal  model  matches  the  expected  behavior  and  hence  the  real  component. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 


Figure  54.  Symbol  for  the  photodiode  in  the  QKD  system  architecture. 
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G.2  Photo-diode  Conceptual  Model 


Envin 


Classical 

Detector 


OptOuti 

- ► 


Optlrii 


Ctrlln 


CtrlOut 


Figure  55.  Photodiode  conceptual  model. 


The  conceptual  model  for  a  photodiode  consists  of  one  optical  input  port  {Optini  },  one 
optical  output  port  {OptOuti},  one  environmental  input  port  {Evnin}  and  one  electrical 
controller  input  port  and  one  electrical  controller  output  port  {Ctrlln,  CtrlOut}.  The 
environmental  port  allows  external  sources  to  communicate  changes  in  the  operational 
environment  to  the  photodiode.  The  electrical  controller  ports  allow  for  control  inputs  to  the 
controller  and  responses  from  the  photodiode  to  the  higher  system  functions. 

In  comparison  to  the  photodiode  symbol  used  in  the  QKD  simulation  architecture  shown 
in  Figure  2,  a  single  bidirectional  optical  connection  is  decomposed  into  an  optical  input  and  an 
optical  output  in  the  conceptual  model.  The  electrical  control  port  is  not  shown  for  clarity  in 
Figure  2,  and  is  also  decomposed  in  the  model  into  an  input  port  and  an  output  port.  This  is 
necessary  to  properly  represent  the  behavior  of  the  device  using  the  DEVS  formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  photodiode,  a  small  portion  of  the  signal 
will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model 
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decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  3  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  photodiode  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation  and  output.  External  environmental 
messages  sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the 
photodiode  can  determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent 
condition).  In  either  case,  a  function  determines  how  the  attenuation  and  output  changes  as  a 
function  of  the  device  state  and  current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation.  This 
greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 

G.3  Mathematical  Model 

There  is  no  detailed  mathematical  description  of  the  classical  detector  in  Section  5.8. 

G.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
classical  detector  (photodiode). 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 
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•  OverPower  is  a  flag  which  indicates  if  the  deviee  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  whieh  exeeed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optieal  signal  arrives: 

•  Calculate  the  optieal  power  of  the  signal.  If  the  optieal  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Caleulate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same  port  number. 

•  Output  a  control  message  if  the  optical  power  of  the  signal  exceeds  the  threshold  power 
level 

When  an  environmental  message  arrives: 

•  Update  the  CurrrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

When  a  control  message  arrives: 

•  Respond  to  the  controller  with  an  acknowledgement  message. 


G.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  photodiode  in  the  boxes  and 
the  transitions  represented  by  arrows  between  the  phases.  Eaeh  transition  is  labeled  with  the  type 
of  transition  {Aext  -  external  or  d/„^  -  internal)  and  the  significant  actions  that  take  plaee  during  the 
transition.  Eaeh  are  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value  of  the  time 
advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase  and  an  entry 
showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs.  Note  there  is 
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a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the  photodiode  at 
the  same  time. 


state  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  queue. xl..xn} 


dint/ 

queue=0 


ta=time 
delay 

dext 
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update 
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\1/  set  ta 
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queue  1=0; 
get  queue 
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ta 

ta=  time 
delay 


Passive 

A=0 


dext  OPT/  check  overpower;  insert  (xi,ta) 


dext  ENV/ 
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CTRL/  If 
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dext  CTRL/  update  queue  ta 
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Interrupt 
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insert  (xi, 
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A=  reflection  I 
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K- 


dint/  interrrupt  =Y; 
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ta  = 
time 
Idelay 


dint/  needRespond  =Y  ta=0 


ta=time  delay  dint/  get  queue(min};  set  ta 


dext  OPT/  update  queue  ta;  insert  (xi,ta) 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 


Figure  56.  Photodiode  phase  transition  diagram. 

G.6  Event-Trace  Diagram 

This  section  shows  various  examples  of  packets  entering  the  photodiode.  The  tables  list 
the  states  the  photodiode  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  photodiode,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes. 


Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 
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•  Sigma;  the  time  until  next  internal  transition.  A  0  sigma  indieates  a  transitory  state 

•  Store:  eontents  of  the  store  variable  for  that  state 

•  Temp;  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp;  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Interrupt  Respond:  shows  the  value  of  the  interrupt  respond  variable 

•  Need  Respond:  shows  the  value  of  the  need  respond  variable 

•  Queue:  contents  of  the  queue  for  that  state 

•  Notes;  any  notes  for  that  state 


G.  6.1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  23.  Case  I  state  list. 
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Figure  57.  Case  I  sequence  diagram. 
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G,6,2  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  1  Optical  Packet 
Arriving  Time 
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Figure  58.  Case  II  sequence  diagram. 


252 


G.6.3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time 
2x10^4  and  Multiple  Optical  Packets  Arriving  at  Time  3x10'' 4 


Table  24.  Case  III  state  list. 
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Figure  59.  Case  III  sequence  diagram. 


254 


G.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  SxIO'^d 

Table  25.  Case  IV  state  list. 
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G.6.5  CASE  V:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Control  Packet  Arriving  at  Time  3 

Table  26.  Case  V  state  list. 
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Figure  60.  Case  V  sequence  diagram. 

G.  7  Photodiode  Parallel  DEVS  Code 

Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 


256 


•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  seales  involved  and  the  length  of  time  neeessary  for  temperature  fluetuations. 

•  The  eomponent  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  “needRespond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  photodiode  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  8 ext,  8i„t,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp)  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp}  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  ~  q-K  ^  5*  is  the  external  state  transition  function; 

Sint  =  S  S  is  the  internal  state  transition  function; 

Seon  =  Q^Xl  ^  iS  is  the  confluent  transition  function; 

/I  =  5*  — >  T*  is  the  output  function; 

to  =  S'^^Uooor5'^  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  5*,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  photodiode  (Ajv/,  Tm,  iS",  Sexh  Sinty  Scon,  to) 
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where 


tp  =  transmission  time  inside  the  attenuator 
temperature  ~  eurrent  temperature  of  the  attenuator 

phase  -  eontrol  state  that  keeps  traek  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “refleet”,  “respond”,  “update  deteetor”} 

overtemp  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  optieal  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
needRespond=  flag  variable  set  when  both  Refleet  and  UpdateDeteetor  respond  to  inputs 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  current  optical  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optical  packet 
messagebag=  variable  that  stores  the  current  x  input  value(s)  {p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optical  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 
reflect  =  variable  that  stores  the  current  reflected  optical  packet 
reflect.port  =  variable  that  holds  the  current  reflection  output  port 
reflect.power  =  variable  that  holds  the  current  reflection  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
ctrlOutput  =  variable  that  stores  the  output  control  message  response 
responseOutput  =  variable  that  stores  the  output  detection  message 
queue.current  =  variable  that  holds  the  currently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
e  =  elapsed  time  since  last  transition  occurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  scheduled  inputs 
queue_size()  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_refiected()  =  method  returns  the  first  unreflected  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_reflected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
ctrlMsgO  =  method  that  generates  a  response  message  to  received  control  messages 
outputMsgO  =  method  that  generates  the  response  message  to  received  optical  packets 
insert_event_q()  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 
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calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  fistore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  /{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  j{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  J{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  j{current.v,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReflectedO  =  method  that  calculates  reflection  power  of  an  optical  packet 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 

q.Vmm  =  minimum  value  in  the  queue 

v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 
InPorts  =  {“Optini”,  “Envin”,  “Ctrlln”}  with 

Xm  =  {(“Optini”,  Vopt),  (“Envin”,  Venv),  (“Ctrlln”,  Vctri)}  is  the  set  of  input  ports  and  values. 
OutPorts  =  {“OptOuti”,  “CtrlOut”}  with 

Ym=  {(“OptOuti”,  Yoptouti),  (“CtrlOut”,  Yctriout)}  is  the  set  of  output  ports  and  values. 
phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  queue) 

=  {{“passive”,  “reflect”,  “respond”,  “update  detector”}  x  E  x  R  x  {“Y”,  “N”}  x 

{“Y”,”N”}  X  {“Y”,”N”}  X  {“Y”,”N”}  x  V) 

External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond ,  queue, 

e,  {{pi,Vi),....  {pn,Vn)))  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

queue.xl  ..xn) 

if  phase  =  “passive”  and  p  =  “Optini” 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 


259 


remove_event_m(cMrrenO 
queue.current  =  queue_first(^MeMe) 
reflect  =  {queue. current. p),  caicRe^[QCiQd{queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflect”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  =  “Optini” 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_need_reflected() 
reflect  =  (queue,  current.p),  ca\cRQf[QCtQd{queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond^  “Y” 
timeLeftRespond  =  timcLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

queue. x\..xn) 

if  phase  =  “passive”  and  p  —  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  queue.xl . .xn) 

if  phase  =  “respond”  and  p  =  “Envin” 

update_delay(^MeMe) 

timeLeftRespond  =  time,  delay-  e 

temperature  =  messagebag.temperature 

if  temperature  >  damage,  temp 

overtemp  =  “Y” 

time,  delay  =  timeLeftRespond 

(“update  detector”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

queue.xl.. xn) 

if  phase  =  “passive”  and  p  =  “Ctrlln” 
ctrlOutput  =  cix\Msg{store) 

(“update  detector”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

queue. x\..xn) 
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if  phase  =  “respond”  and  p  —  “Ctrlln” 
update_delay(^MeMe) 
ctrlOutput  =  ctrlMsg(5tore) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 


{phase,  a 
otherwise; 


e,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

queue. x\..xn) 


Internal  Transition  Function: 


dintiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  queue)= 
(“refleet”,  0,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  queue. x\ ..xn)) 
if  phase  =  “refleet”  and  need.reflect  !=  null 
need.reflect  =  queue_need_refleeted() 
current  =  need.reflect 

reflect  =  (current.p),  ealeRefleeted(cMrrent.v)) 
mark_refleeted(cMrrent) 


(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  queue.x\..xn) 

if  phase  =  “refleot”  and  need.reflect  =  null 
need.reflect  =  queue_need_refleoted() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
time.delay  =  eurrent.time. delay 

responseOutput=  outputMsg(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr) 

timeLeftRespond  =  propagation  delay 

else 

time.delay  =  timeLeftRespond 

(“update  deteetor”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

queue. x\..xn) 

if  phase  =  “refleet”  and  needRespond  =  “Y” 

CtrlOutput  =  etrlMsg(5tore) 

(“respond”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  queue.x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  eurrent.time. delay 

responseOutput=  outputMsg(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr) 
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interruptRespond=  “N” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interrupt  Respond, 

needRespond,  queue. x\..xn) 

if  phase  =  “update  detector”  and  interruptRespond  =  ”Y” 
time. delay  =  timeLeftRespond 

(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  overpower,  interruptRespond, 

needRespond,  cur  rent  Attenuation,  queue.x\..xn) 
if  phase  =  “update  detector”  and  interruptRespond  =  “N”  and  needRespond  =  “Y” 
current  =  queue_min() 
time.delay  =  current.time. delay 

responseOutput=  outputMsg(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr) 
timeLeftRespond  =  propagation  delay 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  overpower,  interruptRespond, 

needRespond,  queue. x\..xn) 


if  phase  =  “update  detector”  and  interruptRespond  =  ”N” 


(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 


Confluence  Function: 


dcon{s,  ta{s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  queue)  = 
(reflect. p,  reflect,  v) 
if  phase  =  “reflect” 

(Outputi,  responseOutput) 
if  phase  =  “respond” 

(“CtrlOut”,  ctrlOutput) 
if  phase  =  “update  detector” 

0  (null  output) 
otherwise; 

Time  advance  Function: 
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taiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  queue)  = 

O', 


G.8  Mathematical  model 


I  I  intrinsic  parameters 

threshold  =  par("threshold");  //  e  field  threshold  (V/m) 

eonversionFactor  =  par("oonversionFaotor");  //  eonversion  faetor 

generateReflections  =  par("generateReflections"); 

insertionLoss  =  par("insertionLoss");  //  insertion  loss  (dB) 

returnLoss  =  par("returnLoss");  //  return  loss  (dB) 

degradedAttenuation  =  par("degradedAttenuation");  //  degraded  attenuation  (0.0-1 .0) 

damagedAttenuation  =  par("damagedAttenuation");  //  damaged  attenuation  (0.0-1 .0) 

tempDegradeXhreshold  =  par("tempDegrade Threshold");  //  temperature  degrade  threshold  (C) 

tempDamageXhreshold  =  par("tempDamageThreshold");  //  temperature  damage  threshold  (C) 

powerDegradeThreshold  =  par("powerDegradeThreshold");  //  power  degrade  threshold  (Watts) 

powerDamageThreshold  =  par("powerDamageThreshold");  //  power  damage  threshold  (Watts) 

propagationDelay  =  par("propagationDelay");  //  propagation  delay  (see) 

displaylnputPulse  =  par("displaylnputPulse");  //  display  input  pulse  parameters 

computelnputPulsePower  =  par("eomputeInputPulsePower");  //  eompute  input  pulse  power 


//  extrinsie  parameters 

temperatureMean  =  par("temperatureMean");  //  temperature  mean  (C) 

temperatureStdDev  =  par("temperatureStdDev");  //  temperature  standard  deviation  (C) 


Generate  a  refleetion: 
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outAmplitude  =  amplitude  *  std::sqrt((std::pow(10.0,  (-1.0*returnLoss/10.0)))); 

outGlobalPhase  =  globalPhaseRange(globalPhase+PI); 

outOrientation  =  orientationRange(orientation); 

outEllipticity  =  ellipticityRange(ellipticity); 

outCentralFreq  =  centralFreq; 


G.9  Component  Use  Case 

G.9.1  Respond  to  an  Optical  Packet  in  the  Classical  Detector  (CD) 

Optical  packet  arrives  at  the  CD.  A  portion  of  optical  packet  reflects  back  down  incoming 
optical  line.  Place  the  optical  packet  into  the  optical  queue.  Check  to  see  if  optical  packet 
overpowers  the  CD.  Records  overpower  condition,  if  applicable.  Remove  the  optical  packet  from 
the  queue  and  create  a  control  output  signal  based  on  the  input  signal  and  the  current  component 
state.  Send  the  control  output  signal  out  of  the  component  control  port. 


•  Identified  Alternative  Uses  Cases 

o  Respond  to  a  control  message 
o  React  to  an  environmental  message 

•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
o  Reflections  are  not  affected  by  component  state 
o  Incoming  electrical  signals  are  not  affected  by  component  state 
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Initialization 

No  Optical  Output 


ormal  Stal 

pected  Optic 

L 

Output 

Under  degraded 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


Degraded  State 

Reduced  Optical 
Output 


Over  damaged 
temperature  or 
power  threshold 


Damaged  State 

No  Optical  Output 


Over  damaged 
temperature  or 
power  threshold 


•Reflections  are  not  configured  to  be  effected  by  state 
•Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  61.  Component  states. 


State  =  {phase,  o,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  queue. xl..xn} 
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dint/  interrrupt  =Y; 
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*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 


Figure  62.  Photodiode  phase  transition  diagram. 

G.  9.2  Respond  to  Optical  Packet  End  Goals 


•  Optical  packet  reflected  properly. 

•  Optical  packet  entered  and  removed  from  queue  in  proper  sequence. 

•  Overpower  condition  properly  recognized  and  recorded. 
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•  Control  message  ereated  and  sent  out  the  correet  port  at  the  eorreet  time. 

G.9.3  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  reflected  properly. 

•  Optical  packet  entered  and  removed  from  queue  in  proper  sequence. 

•  Overpower  condition  properly  recognized  and  recorded. 

•  Optical  packet  attenuated  properly  to  the  limit  of  accuracy. 

•  Optical  packet  propagated  out  the  correct  port  at  the  correct  time. 

G.9.4  Respond  to  an  Environmental  Packet  in  the  Classical  Detector  (CD) 

Environmental  packet  arrives  at  the  component.  Check  to  see  if  environmental  packet 
temperature  sets  the  component  to  degraded  or  damaged  state.  Check  to  see  if  temperature  level 
returns  component  from  degraded  state  to  normal  state.  Records  change  in  condition,  if 
applicable.  Change  component  function  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

G.  9. 5  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 

•  Overtemperature  condition  properly  recognized  and  recorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

G.9. 6  Respond  to  a  Control  Message  in  the  Classical  Detector  (CD) 

Control  Message  arrives  at  the  component.  Component  decodes  message  properly.  Records 
change  in  condition  or  state,  if  applicable.  Change  component  function  if  in  degraded  or 
damaged  state  or  by  change  in  component  condition,  if  necessary. 

•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
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G.9. 7  Respond  to  Control  Message  End  Goals 

•  Control  message  reeeived  properly 

•  Change  of  eondition  or  state  eompleted  and  reeorded  properly,  if  neeessary 

•  Change  eomponent  funetion  properly,  if  neeessary 

G.IO  Optical  Photo-diode  Test  Cases 

Each  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  check  behavior  and  timing.  Each  component  had 
each  of  its  input  ports  (optical,  environmental  (env),  and/or  control  (ctrl))  tested  singly,  then  in 
different  combinations  of  ports  and  input  messages.  All  identified  errors  were  corrected  and  the 
component  retested  until  it  functioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  processing. 
Control  messages  work  in  the  same  way,  but  force  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
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SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 

Table  6.  Optical  Photo-diode  Test  Cases 


Inject  Port 

Running  Totals 

opt 

env 

Ctrl 

Phase 

Case 

Optl 

Ctrl 

Env 

Notes 

# 

# 

# 

Passive 

1 

1 

0 

0 

single 

1 

0 

0 

2 

0 

1 

0 

single 

1 

0 

1 

3 

0 

0 

1 

single 

1 

1 

1 

4 

1 

1 

0 

same  time 

2 

1 

2 

differ 

5 

1 

1 

0 

time 

3 

1 

3 

6 

1 

1 

1 

same  time 

4 

2 

4 

differ 

7 

1 

1 

1 

time 

5 

3 

5 

8 

0 

1 

1 

same  time 

5 

4 

6 

differ 

9 

0 

1 

1 

time 

5 

5 

7 

10 

1 

0 

1 

same  time 

6 

6 

7 

differ 

11 

1 

0 

1 

time 

7 

7 

7 

20 

2 

0 

0 

same  time 

9 

7 

7 

21 

0 

1 

0 

same  time 

9 

7 

8 

22 

2 

1 

0 

same  time 

11 

7 

9 

differ 

23 

2 

1 

0 

time 

13 

7 

10 

24 

2 

1 

1 

same  time 

15 

8 

11 

differ 

25 

2 

1 

1 

time 

17 

9 

12 

26 

0 

1 

1 

same  time 

17 

10 

13 

differ 

27 

0 

1 

1 

time 

17 

11 

14 

28 

2 

0 

1 

same  time 

19 

12 

14 

differ 

29 

2 

0 

1 

time 

21 

13 

14 

totals 

21 

14 

13 

Respond 

41 

2 

0 

0 

single 

23 

13 

14 

42 

1 

1 

0 

single 

24 

13 

15 

43 

1 

0 

1 

single 

25 

14 

15 

44 

2 

1 

0 

same  time 

27 

14 

16 

differ 

45 

2 

1 

0 

time 

29 

14 

17 
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46 

2 

1 

1 

same  time 

31 

15 

18 

differ 

47 

2 

1 

1 

time 

33 

16 

19 

48 

1 

1 

1 

same  time 

34 

17 

20 

differ 

49 

1 

1 

1 

time 

35 

18 

21 

50 

2 

0 

1 

same  time 

37 

19 

21 

differ 

51 

2 

0 

1 

time 

39 

20 

21 

60 

3 

0 

0 

same  time 

42 

20 

21 

61 

1 

1 

0 

same  time 

43 

20 

22 

62 

3 

1 

0 

same  time 

46 

20 

23 

differ 

63 

3 

1 

0 

time 

49 

20 

24 

64 

3 

1 

1 

same  time 

52 

21 

25 

differ 

65 

3 

1 

1 

time 

55 

22 

26 

66 

1 

1 

1 

same  time 

56 

23 

27 

differ 

67 

1 

1 

1 

time 

57 

24 

28 

68 

3 

0 

1 

same  time 

60 

25 

28 

differ 

69 

3 

0 

1 

time 

63 

26 

28 

totals 

42 

14 

13 

TCI 

1 

1 

2 

single 

64 

28 

29 

TC2 

1 

1 

2 

single 

65 

30 

30 

TC3 

1 

1 

2 

single 

66 

32 

31 

TC4 

1 

1 

2 

single 

67 

34 

32 

TC5 

1 

1 

2 

single 

68 

36 

33 

TC6 

1 

1 

2 

single 

69 

38 

34 

TC7 

1 

0 

2 

single 

70 

40 

34 

totals 

7 

6 

14 

23  -  INIT  control  message  sent;  OPTl  &  Ctrl  -  differ  time  - 

Notes:  Passive 

24  -  INIT  control  message  sent  -  OPTl  &  Ctrl  -  same  time  - 
Passive 

63  -  INIT  control  message  sent  -  OPTl  &  Ctrl  -  same  time  - 
Respond 

66  -  INIT  control  message  sent  -  Ctrl  &  ENV  -  same  time  - 
Respond 
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Appendix  H  -  Electronically  Controlled  Variable  Optical  Attenuator 

(EVOA) 

H.l  Device  Description 

The  EVOA  is  used  to  attenuate  the  power  of  optical  signals  by  a  variable  amount, 
usually  expressed  in  decibels  (dBs).  These  devices  usually  have  some  form  of  blocking  material 
such  as  an  opaque  slab  or  a  window  that  is  tilted  in  the  path  of  the  light.  This  blocking  material  is 
connected  to  an  electric  motor  that  is  controlled  by  the  higher  system  functions,  allowing  for  a 
variable  amount  of  light  to  exit  the  device.  Broadband  versions  of  the  device  may  use  a  tilting 
window  that  the  light  passes  through  rather  than  an  opaque  block.  See  Figure  1  for  an  example  of 
the  internals  of  a  VO  A  and  Figure  2  for  an  example  of  an  EVOA. 


(Direction 
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'TT*  Narrowband  VOA 
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Broadband  VOA 


Focusing 

Lens 


Figure  63.  Example  of  the  internals  of  a  VOA  (ThorEabs,  2013). 


4 

Figure  64.  View  of  an  EVOA  (OZOptics,  2013) 


The  EVOA  is  a  bidirectional  optical  component  with  two  optical  ports.  Optical  signals 


arriving  at  one  of  the  ports  is  attenuated  and  propagated  to  the  other  port  after  a  defined 
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propagation  delay.  The  EVOA  is  sensitive  to  the  power  of  the  optieal  signals  that  are  propagated 
through  the  eomponent.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold,  the  EVOA 
may  become  permanently  damaged  which  changes  its  attenuation  characteristics.  Similarly,  the 
EVOA  is  sensitive  to  the  temperature  in  the  environment  in  which  it  operates.  If  the  temperature 
exceeds  defined  thresholds,  the  EVOA  may  become  temporarily  degraded  or  permanently 
damaged  which  changes  its  attenuation  characteristics.  If  temporarily  degraded,  the  device  may 
recover  to  normal  operating  behavior  after  the  temperature  returns  to  a  “normal”  operating 
temperature. 

The  first  step  involved  with  the  modeling  the  EVOA  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica  software 
program  that  modeled  the  EVOA.  The  SME  developed  a  series  of  use  cases  that  exercised  the 
functionality  of  the  device  over  a  wide  variety  of  conditions  and  verified  the  model  and  validated 
the  input  and  output  behavior  of  the  device  within  a  single  Mathematica  model  (worksheet).  The 
Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME  communicated  the 
behavior  of  the  EVOA  to  the  researcher.  Additional  information  came  from  product  data  sheets 
from  commercial  vendors  and  standard  texts  from  the  optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  EVOA 
using  the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated  to  the 
detailed  development  of  the  DEVS  model  of  the  EVOA.  Once  developed,  the  model  will  be 
simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  in  the  Mathematica 
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worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that  the  DEVS 
formal  model  matehes  the  behavior  of  the  Mathematiea  model  and  henee  the  real  eomponent. 

Onee  eompleted,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
ereated  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
eonstruetion  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 

E 
V 

O  2 
A 

Figure  65.  Symbol  for  the  EVOA  in  the  QKD  system  arehiteeture. 

H.2  EVOA  Conceptual  Model 


1 


Figure  66.  EVOA  eoneeptual  model. 


The  eoneeptual  model  for  an  EVOA  eonsists  of  two  optieal  input  ports  {Opthii,  OptIn2}, 
two  optieal  output  ports  {OptOuti,  OptOut2},  one  environmental  input  port  {Evnin}  and  one 
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electrical  controller  input  port  and  one  electrical  controller  output  port  {Ctrlln,  CtrlOut}.  The 
environmental  port  allows  external  sources  to  communicate  changes  in  the  operational 
environment  to  the  EVOA.  The  electrical  controller  ports  allow  for  control  inputs  to  the 
controller  and  responses  from  the  EVOA  to  the  higher  system  functions. 

In  comparison  to  the  EVOA  symbol  used  in  the  QKD  simulation  architecture  shown  in 
Eigure  3,  a  single  bidirectional  optical  connection  is  decomposed  into  an  optical  input  and  an 
optical  output  in  the  conceptual  model.  The  electrical  control  port  is  not  shown  for  clarity  in 
Eigure  2,  and  is  also  decomposed  in  the  model  into  an  input  port  and  an  output  port.  This  is 
necessary  to  properly  represent  the  behavior  of  the  device  using  the  DEVS  formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  EVOA,  a  small  portion  of  the  signal  will 
be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model  decomposes 
each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Eig.  4  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  EVOA  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation.  External  environmental  messages 
sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the  EVOA  can 
determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In  either 
case,  a  function  determines  how  the  propagation  changes  as  a  function  of  the  device  state  and 
current  temperature. 
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When  multiple  optieal  signals  arrive  at  a  port  at  the  same  time,  they  will  be  proeessed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation.  This 
greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 

H.3  Mathematical  Model 

For  a  detailed  mathematical  description  of  the  EVOA,  refer  to  Section  6.8  which  contains 
the  Mathematica  worksheet  provided  by  the  optical  physics  SME. 

H.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
EVOA. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Determine  the  input  port  number. 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Place  the  optical  packet  into  the  queue 

•  Immediately  calculate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same 
port  number. 
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•  Remove  the  paeket  from  the  queue;  ealeulate  the  attenuated  output  optieal  signal  based 
upon  the  input  optieal  signal,  the  OverPower  flag,  the  OverTemp  flag,  and  the  eurrent 
environment. 

•  Send  the  attenuated  output  signal  out  of  the  optieal  output  port  number  that  is  not  the 
same  as  the  input  port  number. 

When  an  environmental  message  arrives: 

•  Update  the  Current! emp  with  the  eurrent  temperature  eontained  in  the  environmental 
message. 

•  If  the  eurrent  temperature  exeeeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

When  a  eontrol  message  arrives: 

•  Inerease  or  deerease  the  attenuation  per  the  eontrol  message  as  a  function  of  time  and  the 
attenuation  rate  of  change. 

•  Respond  to  controller  if  the  maximum  or  minimum  attenuation  of  the  EVOA  is  reached 
and  ensure  that  these  values  are  not  exceeded. 

H.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  EVOA  in  the  boxes  and 
the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled  with  the  type 
of  transition  (d^^  -  external  or  d/„^  -  internal)  and  the  significant  actions  that  take  place  during  the 
transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value  of  the  time 
advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase  and  an  entry 
showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs.  Note  there  is 
a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the  EVOA  at  the 
same  time. 
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state  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  interruptUpdate, 
needRespond,  currentAttenuation,  newAttenuation,  aueue.xl..xn'V 
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Figure  67.  EVOA  phase  transition  diagram. 

H.6  Event-Trace  Diagram 


This  section  shows  various  examples  of  packets  entering  the  EVOA.  The  tables  list  the 
states  the  EVOA  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state  number, 
with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state  variable, 
current  temperature  of  the  EVOA,  the  over  temperature  flag  variable  and  the  over  power  flag 
variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents  of  the  store 
state  variable  and  any  notes. 


Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 
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•  Queue:  contents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 

H.  6.1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 


Table  27.  Case  I  state  list. 
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Figure  68.  Case  I  sequence  diagram. 

H.  6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  28.  Case  II  state  list. 
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Figure  69.  Case  II  sequence  diagram. 


H.6.3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 


Table  29.  Case  III  state  list. 
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Figure  70.  Case  III  sequence  diagram. 

H.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 


Table  30.  Case  IV state  list. 
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Figure  71.  Case  IV  sequence  diagram. 

H.6.5  CASE  V:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Control  Packet  Arriving  at  Time  3 


Table  31.  Case  V  state  list. 
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1  packet,  0  environmental  event,  0  external  event,  1  control  event  at  e  =  3 
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Figure  72.  Case  V  sequence  diagram. 

H.  7  EVOA  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  Assume  that  only  one  control  packet  will  arrive  at  any  given  time,  due  to  the  small  time 
scales  involved  and  the  length  of  time  necessary  for  attenuation  changes. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”, 
“overpower’V’interruptRespond”,  “interruptUpdate”,  “needRespond”,  “currentAttenuation”, 
“newAttenuation”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
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“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  EVOA  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  8ext,  8int,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp}  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp]  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  0  X  XIj  ^  5*  is  the  external  state  transition  function; 

Sint  =  S'  ^  S'  is  the  internal  state  transition  function; 

Scon  =  2  X  S  is  the  confluent  transition  function; 

=  S  ^  y*  is  the  output  function; 
ta  =  S  ^  iCli  CO  or  S  ^  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS EYQji  (X/jf,  S,  Sgxty  Sinf,  Scorn 
where 

tp  ~  transmission  time  inside  the  attenuator 
temperature  =  current  temperature  of  the  attenuator 
phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “reflect”,  “respond”,  “update  attenuation”} 
overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
interruptUpdate  =  flag  variable  set  when  ElpdateAttenuation  phase  is  interrupted  by  an  external 
event 

needRespond=  flag  variable  set  when  both  Reflect  and  ElpdateAttenuation  respond  to  inputs 
currentAttenuation  =  current  attenuation  of  the  EVOA 

newAttenuation  =  attenuation  the  EVOA  is  changing  to  after  receiving  a  change  message 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  current  optical  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optical  packet 
messagebag=  variable  that  stores  the  current  x  input  value(s)  {p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optical  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
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current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 
reflect  =  variable  that  stores  the  current  reflected  optical  packet 
reflect.port  =  variable  that  holds  the  current  reflection  output  port 
reflect.power  =  variable  that  holds  the  current  reflection  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
ctrlOutput  =  variable  that  stores  the  output  control  message  response 
queue.current  =  variable  that  holds  the  currently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
attenuationMin  =  minimum  selectable  attenuation 
attenuationMax  =  maximum  selectable  attenuation 
e  =  elapsed  time  since  last  transition  occurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  scheduled  inputs 
queue  sizeO  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_first()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_reflected()  =  method  returns  the  first  unreflected  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_reflected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
ctrlMsgO  =  method  that  generates  a  response  message  to  received  control  messages 
outputMsgO  =  method  that  generates  the  response  message  to  received  optical  packets 
insert_event_q()  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  f{store,  temperature, 
overtemp,  peakpwr,  overpwr,  currentAttenuation,  newAttenuation) 
changeAttenuationO  =  method  that  changes  current  attenuation  of  the  EVOA 
calcReflectedO  =  method  that  calculates  reflection  power  of  an  optical  packet 
MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 
q.Vmm  =  minimum  value  in  the  queue 
v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 
InPorts  =  {“Optini”,  “OptIn2”,  “Envin”,  “Ctrlln”}  with 
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Xm  =  {(“Optini”,  Vopt),  (“0ptln2”,  Vopi),  (“Envin”,  Venv),  (“Ctrlln”,  Vctrd)  is  the  set  of  input 
ports  and  values. 

OutPorts  =  {“OptOuti”,  “OptOut2”,  “CtrlOut”}  with 
Ym  =  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  Yoptouti),  (“CtrlOut”,  Yctrioud)  is  the  set  of  output 
ports  and  values. 

phase  is  a  eontrol  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interrupt  Respond,  interrupt  Update, 
needRespond,  cur  rent  Attenuation,  newAttenuation,  queue)  =  {{“passive”,  “reflect”,  “respond”, 

“update  attenuation”}  x  Ex  i?  x  {“Y”,  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x 
{“Y”,”N”}  X  E  X  E  X  E} 


External  Transition  Function: 

dextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  interrupt  Update, 
needRespond ,  currentAttenuation,  newAttenuation,  queue,  e,  ((/?/, v/),....  {p„,Vn)))  = 
(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  interruptUpdate, 

needRespond,  currentAttenuation,  newAttenuation  queue.xl ..xn) 
if  phase  =  “passive”  and  p  E  {“Optini”,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_lirst(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  interruptUpdate, 

needRespond,  currentAttenuation,  newAttenuation  queue.xl  ..xn) 
if  phase  =  “update  attenuation”  and  p  G  {“Optini”,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue. first(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
if  currentAttenuation  !=  newAttenuation 
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currentAttenuation  =  c  ale  Attenf^  tore,  v,  temperature,  overtemp,  peakpwr,  overpwr, 
currentAttenuation,  new  Attenuation) 
timeLeftUpdate  =  timeLeftUpdate-  e 

(“reflect”,  0,  store,  temperature,  overtemp,  overpower,  interrupt  Respond,  interruptUpdate, 

needRespond,  currentAttenuation,  newAttenuation  queue.xl  ..xn) 
if  phase  =  “respond”  and  p  E  {“Optini”,  “OptIn2”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrenO 
remove_event_m(cMrrent) 
queue. current  =  queue_need_refleoted() 
reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
if  currentAttenuation  !=  newAttenuation 

currentAttenuation  =  c ale Attenf^ tore,  v,  temperature,  overtemp,  peakpwr,  overpwr, 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  interruptUpdate, 

needRespond,  currentAttenuation,  newAttenuation  queue.xl  ..xn) 
if  phase  =  “passive”  and  p  —  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
interruptUpdate,  needRespond,  currentAttenuation,  newAttenuation  queue.xl.. xn) 
if  phase  =  “respond”  and  p  —  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time. delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

if  currentAttenuation  !=  newAttenuation 

currentAttenuation  =  ealoAttenf^tore.v,  temperature,  overtemp,  peakpwr,  overpwr, 
time. delay  =  timeLeftRespond 

(“update  attenuation”,  time. delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
interruptUpdate,  needRespond,  currentAttenuation,  newAttenuation  queue.xl.. xn) 
if  phase  =  “update  attenuation”  and  p  —  “Envin” 
update_delay(^MeMe) 
temperature  =  messagebag.temperature 
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if  temperature  >  damage,  temp 

overtemp  =  “Y” 

if  currentAttenuation  !=  newAttenuation 

currentAttenuation  =  calc Atten(iy tore. v,  temperature,  overtemp,  peakpwr,  overpwr, 
current  A  ttenuation,  new  A  ttenuation) 
timeLeftUpdate  =  time. delay-  e 
time.delay  =  timeLeftUpdate 

(“update  attenuation”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
interrupt  Update,  needRespond,  currentAttenuation,  newAttenuation  queue.xl.jcn) 

if  phase  =  “passive”  and  p  —  “Ctrlln” 
ctrlOutput  =  etrlMsg(5tore) 
currentAttenuation  =  ehangeAttenuation(5tore) 
if  currentAttenuation  <  attenuationMin 
currentAttenuation  =  attenuationMin 
if  currentAttenuation  <  attenuationMax 
currentAttenuation  =  attenuationMax 

(“update  attenuation”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
interruptUpdate,  needRespond,  currentAttenuation,  newAttenuation  queue.xl.jcn) 
if  phase  =  “respond”  and  p  =  “Ctrlln” 
update_delay(^MeMe) 

CtrlOutput  =  ctrlMsg(5tore) 
if  currentAttenuation  !=  newAttenuation 

currentAttenuation  =  calcAttenf^tore.v,  temperature,  overtemp,  peakpwr,  overpwr, 
currentAttenuation  =  changeAttenuation(5tore) 
if  currentAttenuation  <  attenuationMin 
currentAttenuation  =  attenuationMin 
else 

if  currentAttenuation  <  attenuationMax 
currentAttenuation  =  attenuationMax 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“update  attenuation”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
interruptUpdate,  needRespond,  currentAttenuation,  newAttenuation  queue.xl.jcn) 
if  phase  =  “update  attenuation”  and  p  —  “Ctrlln” 
update_delay(^MeMe) 

CtrlOutput  =  ctrlMsg(5tore) 
if  currentAttenuation  !=  newAttenuation 

currentAttenuation  =  calcAttenf^tore.v,  temperature,  overtemp,  peakpwr,  overpwr, 
current  A  ttenuation,  new  A  ttenuation) 

currentAttenuation  =  changeAttenuation(5tore) 
if  currentAttenuation  <  attenuationMin 
currentAttenuation  =  attenuationMin 
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else 

if  currentAttenuation  <  attenuationMax 
currentAttenuation  =  attenuationMax 
interruptUpdate=  “Y” 
timeLeftUpdate=  timeLeftUpdate  -  e 


{phase,  cr  -  e,  00,  store,  temperature,  overtemp,  overpower,  interruptRespond,  interruptUpdate, 

needRespond,  currentAttenuation,  newAttenuation  queue.x\..xn) 


otherwise; 

Internal  Transition  Function: 


dintiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  interruptUpdate, 

needRespond,  currentAttenuation,  newAttenuation  queue)= 
(“refleet”,  0,  temperature,  overtemp,  overpower,  interruptRespond,  interruptUpdate, 

needRespond,  currentAttenuation,  newAttenuation  queue. x\..xn)) 
if  phase  =  “refleet”  and  need.reflect  !=  null 
need.reflect  =  queue_need_refleeted() 
current  =  need.reflect 

reflect  =  (current. p),  ealeRefleeted(cMrrent.v)) 
mark_refleeted(cMrrent) 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
interruptUpdate,  needRespond,  currentAttenuation,  newAttenuation  queue.x\..xn) 
if  phase  =  “refleot”  and  need.reflect  =  null 
need.reflect  =  queue_need_refleoted() 
if  interruptRespond  =  “N” 
current  =  queue. min() 
time.delay  =  eurrent.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  ealeAttenfitore.v,  temperature,  overtemp,  peakpwr,  overpwr, 

currentAttenuation,  newAttenuation) 
outputPort  =  “OptOuti” 
if  InPort  =  “Optini” 

outputPulse  =  ealoAttenfitore.v,  temperature,  overtemp,  peakpwr,  overpwr, 

currentAttenuation,  newAttenuation) 
outputPort  =  “OptOuti” 
timeLeftRespond  =  propagation  delay 
else 

time.delay  =  timeLeftRespond 

(“update  attenuation”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
interruptUpdate,  needRespond,  currentAttenuation,  newAttenuation  queue.xl.jcn) 
if  phase  =  “refleot”  and  needRespond  =  “Y” 
ctrlOutput  =  otrlMsg(5tore) 
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(“update  attenuation”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
interrupt  Update,  needRespond,  cur  rent  Attenuation,  newAttenuation  queue.x\..xn) 
if  phase  =  “respond”  and  (eurrentAttenation  !=  newAttenuation) 
if  currentAttenuation  !=  newAttenuation 

currentAttenuation  =  ealoAttenf^tore.v,  temperature,  overtemp,  peakpwr,  overpwr, 
currentAttenuation,  newAttenuation) 
time.delay  =  timeLeftUpdate 

(“respond”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
interrupt  Update,  needRespond,  currentAttenuation,  newAttenuation  queue.x\..xn) 
if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  currentAttenuation  !=  newAttenuation 

currentAttenuation  =  caleAttenf^tore.v,  temperature,  overtemp,  peakpwr,  overpwr, 
currentAttenuation,  newAttenuation) 
if  InPort  =  “Optlm” 

outputPulse  =  c  ale  Atten(5  tore.  V,  temperature,  overtemp,  peakpwr,  overpwr, 

currentAttenuation,  newAttenuation) 

outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  oalcAtten(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr) 

outputPort  =  “OptOuti” 
interruptRespond=  “N” 
if  currentAttenuation  !=  newAttenuation 

currentAttenuation  =  caleAttenf^tore.v,  temperature,  overtemp,  peakpwr,  overpwr, 
currentAttenuation,  newAttenuation) 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  overpower,  interruptRespond, 
interrupt  Update,  needRespond,  currentAttenuation,  newAttenuation  queue.x\..xn) 
if  phase  =  “update  attenuation”  and  interruptRespond  =  “N” 
interruptUpdate  =  “N” 
needRespond  =  “N” 
interruptRespond  =  “N” 

(“respond”,  time.delay,  store,  temperature,  overtemp,  overpower,  overpower,  interruptRespond, 
interruptUpdate,  needRespond,  currentAttenuation,  newAttenuation  queue.x\..xn) 
if  phase  =  “update  attenuation”  and  interruptRespond  =  “Y” 
if  currentAttenuation  !=  newAttenuation 

currentAttenuation  =  ealoAttenf^tore.v,  temperature,  overtemp,  peakpwr,  overpwr, 
currentAttenuation,  newAttenuation) 
time.delay  =  timeLeftRespond 
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(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
interrupt  Update,  needRespond,  currentAttenuation,  newAttenuation  queue.xl.jcn) 
if  phase  =  “update  attenuation”  and  interruptRespond  =  “N”  and  needRespond  =  “Y” 
current  =  queue. min() 
time.delay  =  current.time. delay 
if  currentAttenuation  !=  newAttenuation 

currentAttenuation  =  c  ale  Atten(5  tore,  v,  temperature,  overtemp,  peakpwr,  overpwr, 
current  A  ttenuation,  new  A  ttenuation) 
if  InPort  =  “Optlm” 

outputPulse  =  c  ale  Atten(5  tore.  V,  temperature,  overtemp,  peakpwr,  overpwr, 

currentAttenuation,  newAttenuation) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  e  ale  Attenfi  tore.  V,  temperature,  overtemp,  peakpwr,  overpwr, 

currentAttenuation,  newAttenuation) 
outputPort  =  “OptOuti” 
timeLeftRespond  =  propagation  delay 

(“update  attenuation”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
interrupt  Update,  needRespond,  currentAttenuation,  newAttenuation  queue.xl.jcn) 
if  phase  =  “update  attenuation”  and  interruptUpdate  =  “Y”  and  needRespond  =  “N” 
if  current. Attenuation  !=  newAttenuation 

currentAttenuation  =  calcAttenf^tore.v,  temperature,  overtemp,  peakpwr,  overpwr, 
time.delay  =  timeLeftUpdate 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  interruptUpdate, 

needRespond,  currentAttenuation,  newAttenuation  queue.xl  ..xn) 
if  phase  =  “respond”  and  size  =  0  and  (currentAttenation  !=  newAttenuation) 
size=  queue_size() 
interruptUpdate  =  “N” 
needRespond  =  “N” 
interruptRespond  =  “N” 

Confluence  Function: 


dconis,  ta{s),  x)  =  SextiSintis),  0,  x); 

Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  interruptUpdate, 
needRespond,  currentAttenuation,  newAttenuation  queue)  = 

(reflect. p,  reflect. v) 
if  phase  =  “refleet” 

(outputPort,  outputPulse) 
if  phase  =  “respond” 

("CtrlOut",  ctrlOutput) 
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if  phase  =  "update  attenuation 


0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  interrupt  Update, 

needRespond,  cur  rent  Attenuation,  newAttenuation  queue)  =  cr; 
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H.8  Mathematical  Model 


Pulse  propagation  considerations  for  the  Electronic  Variable  Optical 
Attenuator  (EVOA)  Module  within  the  QKD  OMNet+^f  simulation 
environment 

Tht  (^IccUioiiic  variable  ofilical  attciuialor  (EVOA)  is  a  device  ubich  conlrols  the  oulput  optical  [rower  of  a  sj'steni. 
lypicall>'  »a  a  feedbaclL  loop.  EVOAs  t>'pkally  use  an  opto-mechajiica]  inteiaelim  or  liquid  ci^sal  element  to 
achieve  the  desired  ailenuation.  EVOAs  arc  available  with  all  combinatian  of  ftber  and  cotmcclof  type.  However,  in 
the  current  QKD  s>'stem  design,  the  ’decoy  slate  generator’  module  conlains  only  SMF,  and  will  subsequently  be  Ibe 
bber  type  used  in  this  EV'  O A  module. 

The  operational  ebaraeteristics  arc  as  follows: 

-  light  input  to  port  I  will  cxil  port  2 

-  light  input  to  port  1  will  cxil  port  I 

The  only  siguitkani  modificalkin  to  the  optical  message  will  be  Ihe  amplitude  (power). 

Pulse  Characteristies  (c.g,) 

These  parameters  arc  used  in  Ihe  joncs  representation  of  the  standard  eobereni  pulse  optical  message  packet. 

Pertinent  Pulse  Characteristics  fur  the  E\'OA  Module 

£inl  :«  Bol  («  ■lactz'ic  £i«Xd  input  into  port  1 
£in2  iM  Ea2  («  alactric  £i«ld  iisput  into  port  2  *) 

The  following"  parameter  values  are  Tram  or  are  modeled  after  COTS  EVO.\s  offered  by  Oz  Optics 
(htrpiyMww.ozoptics.CQin/ALLNEl^^PDF/DTSOOiOvpdf). 

Optical  Specifications 

Icsaxtloas  :«  I.Q  (*  typical  mi m-LTnum  loss  in  tba  dsvic««  lULits  of  *cffi  *)< 

AttstciustionHin  :■  Ins«rtljDss  (*  minimuiD  a«lBctabl«  •attsn.ua'tiDii,  tmits  of  *dB 
JlttsciuationMax  0.1  dB  (*■  maxiBLum  salKtablsi  attuiuAtlDD^  units  of  >dB  -t) 
AttKnustionRssoLution  :■  TdI  (*  toluraiicu  on  thm  spucifiud  attKnuatlcm. 
incraaasa  freon  (D.IdB  A  Idfi)  to  {IdB  A  25clfii)' «  unita  of  dfi  *) 

AttftnuatiDS^>«B<l  :•  100*10^^  (4  quantity  of  tims  tc  chugs  attsimatian  by  1 

quantity  ia  Appx^  units  of  auconcis 

flatLasa  :■  ■  fiO  (4  typical  ratorn  losa , 

signal  raflactad  by  u  input  baam.^  units  of  •dB 

Tmq^H  :•  70  (*  max  cparational  tanqwratura^  unita  of  4) 

TanqhL  :«  -5  («  min  opaxatioaal  tan^jaratura^  units  of  4) 

KuBwr  :a  2000  (4  guTrinmm  oparatianal  powar.^  unita  of  mlf  4) 

RapaattalDdB  0-03 

(*  rapaatability  of  attanoaticui  aatting  up  to  -lOdB^  units  of  4) 

ftapeatta^DdB  :  ■  Q.I 

(4  rapaatability  of  attanuatiem  aatting  from  -10  to  units  of  4/-dB  4} 

RapaattaJ DdB  :  0-3 

(4  rapaatabili ty  of  attanuation  aatting  from  -30  to  units  of  4/-dB  4) 

Rapaattja55dB  :■  0-5 

(4  rapaatability  of  attanuation  satting  from  -40  to  -SSdBj  units  of  ^/-dE  4)' 

RapaattofiOdB  :  1.0 

(4  rapaatability  of  attanuation  satting  from  -53  to  -SOdB.  units  of  4/-dB  4) 
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Electic«yPhvMcil  Specificitiops 

LatchingTypa  :  ■  yas 

(•  darica  will  ramain  at  aalactad  attanuation  whan  voltaga  ia  ranovad  •) 

ContxolVoltaga  :■  5  (•  woltaga  to  activa  atappar  aotor  •) 

PowarCooaunption  :■  ISO  (•  typical  alactrical  powar  conaoaption,  unita  of  aM  *) 

Attenuation  Calculations  for  EVOA 

This  EVOA  is  latching,  meaning  that  it  holds  the  attenuation  to  which  it  was  last  adjusted.  Thus,  for  the  module  we 
have  to  define  a  "CunentAttenuation"  that  will  be  held  until  it  is  again  adjusted.  We  will  assume  that  the  rate  of 
adjustment  is  30  dB/s  for  the  first  generation  module.  It  is  stated  (on  the  website)  that  this  rate  can  change  depending 
on  the  level  of  attenuation,  and  we  may  wish  to  include  this  in  the  future.  There  are  two  ways  that  we  can  handle  the 
attenuation  adjustment:  I.)  in  the  electrical  message  we  can  sigiply  the  dination  of  the  vohage  application,  or  2.)  work 
the  code  to  recognize  the  At  from  the  applicaiton  of  the  drive  voltage,  and  continuously  adjust  the  attenuation  until  the 
receipt  of  a  new  electrical  message  with  "zero*  voltage.  For  this  module  we  will  consider  -5  V  to  drive  the  attenuation 
to  lower  values. 

Pwcdacade  far  the  first  option; 

CurrwntAttannatlon  :■  0  (•  unita  of  dB  •) 

Attwnuationitatw  :■  30  (•  unita  of  dB/swcond  •) 

Received  informaiian  from  electrical  message: 

ContzolVoltagu  :•  S.O  (•  unita  of  Volta  «) 

VoltagaOuration  :■  0.01  (•  unita  of  aaconda  •) 

Calculating  drive  direction  (psucdocode): 
if  ConUolV'oli^e  =  S.O 

DriveDirection  =  1.0; 
eke  if  ConlrolVoltagc  =  >5.0 
DriveDirection  =  -l.O; 
else  if  ControlVoltagc  =  0.0 
DriveDirection  =  0.0 

DciwuDiraction  :■  1.0  (•  placed  foe  uae  aa  an  axaagile  •) 

CurrwntAttanuation  « 

CuczwntAttunuatioD  *  OcivuOiroctioo  •  (VoltagaOucation  •  AttanuationSata) 

Boot2[Binl_,  CurrantAttanuation_]  :•  Binl  • 

(•  caaa:  optical  input  on  poet  1  •) 

Eoutl (Ein2_,  CnzxantAttanuatioo_]  :  ■ 

Ein2  •  y  (•  caaa:  optical  input  on  poet  2  •) 


Psacdacade  far  the  lecoAd  nation: 

CueeantAttanuation  :■  0  (•  unita  of  dB  •) 
AttanuationRata  :■  30  (•  unita  of  dB/aacond  •) 

Received  information  frnm  electrical  message: 

ConteolVoltaga  :«  5.0  (•  unita  of  Volta  *) 
TiaaStaap  :■  tiaia  (*  aaaaaqa  aeeiwal  tiaa  •) 

Calculating  drive  direction  ( psucdocode): 
if  ControlVoli^  =  5.0 


294 


EhivcDiicction  =  1.0; 
cbc  if  ControlVohagc  =  -5.0 
DrivcDiTCction  =  -1.0; 
cbc  if  ContrnIVollagc  =  0.0 
DrivcDirretion  =  0.0 

DxlvaDirKCicn  :■  1.0  pLaud  for  uaa  as  an  exaiiq>Ie  *) 

Calculation  of  atlenuadon  level  i pseudocode); 

OxiginaUittamiaCian  •  CuxrantJSCbanuation 

While  ControIV'ollagc  #  0 

CuxxantAttaci'uati.oD  • 

OxiginaLAttanuatxan  +  DrivaDixactlon  *  (  {CuxxantTijiia  «  TijiiaSXaiig>)  «  JltlLanuatlanflaCB) 

Emita  [Eicil_,  CurxacitAttaiiuatiDn_]  :  •  Einl  *  v/  io-ci.r™.tati-™LiwT7 
(*■  cas« :  optical  input  an  port  1  *jl 
£autl[Ein2_«  Curr«ntXtt«nuatiDi3_]j  :«■ 

Ein2 .  optical  input  on  port  2  .) 

.Vo/.e.‘  Both  optbon-S  need  lo  be  trapped  to  nol  allow  the  attenuatian  to  go  below  .A.ttemialionN'fin  or  above  .4t1enualion- 
Ma.x.  even  with  a  drive  vohage  still  supplied. 

If  we  wish  to  flag  the  attenuator  to  include  undesired  return  (reflected)  messages,  the  following  operatioas  would 
hold  true. 

EtJutl[Einl_,  RatLass_]  :•  Einl  * 

Emit2[Ein2_,  ItatliOss_]  Ein2  * 

Polarizaion  Calculations  for  EVOA 


C<!frS  Wcbaile  nMa: 

b  11  p  vr  w .  u  p  1 1  .mcn/pd  VO  A '!i4)0  L  2  ^  I* 

bupjA^^^w.aimh»Lhfw4ojfKLWtWlileadfiiiii/!inuim'dia/'dtn^akHtiWlU73_VOA>L.4n¥TUL.p(U 
b  LI  p  JAir  vr  w .  tu  uplic  AL  L  N  t  W_  P  D  hVU  T  SOO I  O.pd  r 


H.9  DEVS  MS4ME  Derived  Pseudocode 

EVOA  -  START  PASSIVE 

EVOA  -  START  PASSIVE  EXTERNAE  EVENT 
adjust  clock  based  upon  time  elapsed  since  last  event 
check  for  existing  optical  message 

remove  each  pulse  in  bag  and  store  it  into  a  queued  optical  pulse  buffer 
check  for  existing  env  message 

check  if  the  received  temperature  exceeds  damaged  or  degraded  threshold 
check  for  existing  Ctrl  message 

generate  the  response  message  for  an  incoming  control  message 
set  up  for  first  reflected  pulse  if  optical  pulse  arrived 
go  to  the  Reflect  phase  else  go  to  the  Update  Attenuation  phase 

EVOA  -  START  REEEECT  OUTPUT  EVENT 
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adjust  clock  based  upon  time  advanee 
output  pulse 

EVOA  -  START  REFLECT  INTERNAL  EVENT 
identify  any  pulses  that  have  not  yet  been  reflected  and  reflect  them 
set  up  pulse  to  send  in  Respond  phase 
go  to  the  Respond  phase 

EVOA  -  START  UPDATE  ATTENUATION  EXTERNAL  EVENT 
adjust  clock  based  upon  time  elapsed  since  last  event 
eheck  for  existing  optieal  message 

remove  eaeh  pulse  in  bag  and  store  it  into  a  queued  optieal  pulse  buffer 
eheck  for  existing  env  message 

check  if  the  received  temperature  exceeds  damaged  or  degraded  threshold 
check  for  existing  etrl  message 

generate  the  response  message  for  an  incoming  control  message 
set  up  for  first  reflected  pulse  if  optieal  pulse  arrived 
else  hold  in  the  Update  Attenuation  phase  for  a  change  in  Attenuation 

EVOA  -  START  UPDATE  ATTENUATION  OUTPUT  EVENT 
adjust  clock  based  upon  time  advance 
output  the  response  message 
change  the  current  attenuation 

EVOA  -  START  UPDATE  ATTENUATION  INTERNAL  EVENT 
set  up  pulse  to  send  in  Respond  phase  if  optical  pulse  arrived 
go  to  Respond  if  optical  pulse  arrived 
else  go  to  Update  Attenuation  if  a  control  message  arrived 
else  go  to  Passive 

EVOA  -  START  RESPOND  EXTERNAL  EVENT 
adjust  clock  based  upon  time  elapsed  since  last  event 
adjust  queue 

set  a  flag  that  the  Respond  phase  was  interrupted  by  an  external  event 
cheek  for  existing  optieal  message 

remove  eaeh  pulse  in  bag  and  store  it  into  a  queued  optieal  pulse  buffer 
eheck  for  existing  env  message 

cheek  if  the  reeeived  temperature  exceeds  damaged  or  degraded  threshold 
check  for  existing  etrl  message 

generate  the  response  message  for  an  incoming  control  message 
set  up  for  first  refleeted  pulse  if  optical  pulse  arrived 
go  to  the  Reflect  phase 

else  go  to  the  Update  Attenuation  phase 

EVOA  -  START  RESPOND  OUTPUT  EVENT 
adjust  cloek  based  upon  time  advance 
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adjust  pulse  amplitude  if  damaged  or  degraded 
output  pulse  to  the  eorreet  port 


EVOA  -  START  RESPOND  INTERNAL  EVENT 
adjust  queue 

eheck  if  there  any  pulses  remaining  in  queue 
set  up  the  next  queued  pulse 
pulses  remaining,  so  go  to  Respond 
else  cheek  to  see  if  the  attenuation  is  changing 
attenuation  changing,  go  to  Update  Attenuation 
else  go  to  Passive  phase 

EVOA  -  END  PASSIVE 


H.IO  Component  Use  Case 


H.10.1  Respond  to  an  Optical  Packet  in  the  Electronically  Controlled  Optical  Attenuator 
(EVOA) 

Optical  packet  arrives  at  EVOA.  A  portion  of  optical  packet  reflects  back  down  incoming 
optical  line.  Place  the  optical  packet  into  the  optical  queue.  Check  to  see  if  optical  packet 
overpowers  the  EVOA.  Records  overpower  condition,  if  applicable.  Remove  the  optical  packet 
from  the  queue  and  calculate  the  attenuated  optical  output  signal  based  on  the  input  signal  and 
the  current  component  state.  Propagate  the  attenuated  optical  output  signal  out  of  the  component 
optical  port  that  is  not  the  same  as  the  input  port. 


•  Identified  Alternative  Uses  Cases 

o  Respond  to  a  control  message 
o  React  to  an  environmental  message 

•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
o  Reflections  are  not  affected  by  component  state 
o  Incoming  electrical  signals  are  not  affected  by  component  state 
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Initialization 

No  Optical  Output 


ormal  Stal 

pected  Optic 

L 

Output 

Under  degraded 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


Degraded  State 

Reduced  Optical 
Output 


Over  damaged 
temperature  or 
power  threshold 


Damaged  State 

No  Optical  Output 


Over  damaged 
temperature  or 
power  threshold 


•Reflections  are  not  configured  to  be  effected  by  state 
•Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  73.  Component  states. 


State  s  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  interruptUpdate, 
needResDond«  currentAttenuation.  newAttenuation.  queue. xl..xn> 


dint/ 

queue 

«0 


dext 
ENV/ 
update 
queue  ta; 
set  ta 


ta« 

00 


dext  ENV/  check 
overtemp 


Passive 

A«0 


dext  OPT/  check  overpower;  insert  (xi,ta) 


dext 
CTRL/  if 
passive 


tas  time 


taa  time  delay 


dext  CTRL/  update  queue  ta 


dint/ 

need 

Respond^ 
*  Y 


_  idl 

tastime  delay 

Update 

tint/InterruptChanye  »Ytp.tlmq..tftiay  ^  Attenuation 


dint/ 

interrupt 

Respond 

sN 

ta«time 
delay 

dext  CTRI/ 

update  ta 
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tazo 


dext  OPT/ 
check 
overpower; 
insert  (xi.ta); 
at  sSiema 


ta 

zO 


•dint/ 
insert  (xl, 
•») 


Reflect- 
IA»  reflection  - 

A' 


dint/  InterrruptRespond  «Y; 
needRespondsY;  set  ta 


ta»  time  delay  A»ctrl  msg 


taztime 

delay 


Respond 
A«propagation 


■ainfT — 

lueue  |z0; 
get  queue 
(min);  set 

ta 


Adext  ENV/ 

check 

overtemp 


taztime  delay 


dint/  needRespond  zY 


dint/  get  queue(min};  set  ta 


taztime 

delay 


tazO 


dext  OPT/  update  queue  ta;  insert  (xi,ta)  tazO 


taz 

time 

delay 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the 
same  time 


Figure  74.  EVOA  phase  transition  diagram. 
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H.10.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  reflected  properly. 

•  Optieal  entered  and  removed  from  queue  in  proper  sequenee. 

•  Overpower  eondition  properly  recognized  and  reeorded. 

•  Optical  packet  attenuated  properly  to  the  limit  of  accuracy. 

•  Optical  packet  propagated  out  the  correet  port  at  the  correet  time. 


H.10.3  Respond  to  an  Environmental  Packet  in  the  EVOA 

Environmental  packet  arrives  at  the  component.  Check  to  see  if  environmental  paeket 

temperature  sets  the  eomponent  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level 

returns  component  from  degraded  state  to  normal  state.  Records  change  in  condition,  if 

applicable.  Change  component  function  if  in  degraded  or  damaged  state. 

•  Assumptions 
o  None 


H.10.4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  paeket  received  properly 

•  Overtemperature  condition  properly  reeognized  and  reeorded 

•  Change  of  state  completed  and  reeorded  properly,  if  neeessary 

•  Change  component  function  properly,  if  necessary 

H.10.5  Respond  to  a  Control  Message  in  the  EVOA 

Control  Message  arrives  at  the  component.  Component  deeodes  message  properly.  Records 
change  in  eondition  or  state,  if  applieable.  Change  component  funetion  if  in  degraded  or 
damaged  state  or  by  ehange  in  eomponent  condition,  if  necessary. 

•  Assumptions 

o  Component  has  eompleted  initialization  sequenee  at  least  once 


H.  10.6  Respond  to  Control  Message  End  Goals 
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•  Control  message  reeeived  properly 

•  Change  of  condition  or  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

H.ll  EVOA  Test  Cases 

Each  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  check  behavior  and  timing.  Each  component  had 
each  of  its  input  ports  (optical,  environmental  (env),  and/or  control  (ctrl))  tested  singly,  then  in 
different  combinations  of  ports  and  input  messages.  All  identified  errors  were  corrected  and  the 
component  retested  until  it  functioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  processing. 
Control  messages  work  in  the  same  way,  but  force  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 


300 


SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 


Table  6.  EVOA  Test  Cases. 


Inject  Ports 

Running  Totals 

Phase 

Case 

Optl 

Opt2  Ctrl 

Env 

Notes 

opt  # 

env  # 

Ctrl  # 

Passive 

1 

1 

0 

0 

0 

single 

1 

0 

0 

2 

0 

1 

0 

0 

single 

2 

0 

0 

3 

0 

0 

1 

0 

single 

2 

0 

1 

4 

0 

0 

0 

1 

single 

2 

1 

1 

5 

1 

1 

0 

0 

same  time 

4 

1 

1 

6 

1 

0 

1 

0 

same  time 

5 

1 

2 

7 

1 

1 

0 

0 

differ  time 

7 

1 

2 

8 

1 

0 

1 

0 

differ  time 

8 

1 

3 

9 

1 

1 

1 

1 

same  time 

10 

2 

4 

10 

1 

1 

1 

1 

differ  time 

12 

3 

5 

11 

0 

1 

0 

1 

same  time 

13 

4 

5 

12 

0 

1 

0 

1 

differ  time 

14 

5 

5 

13 

0 

0 

1 

1 

same  time 

14 

6 

6 

14 

0 

0 

1 

1 

differ  time 

14 

7 

7 

15 

1 

0 

0 

1 

same  time 

15 

8 

7 

16 

1 

0 

0 

1 

differ  time 

16 

9 

7 

20 

2 

0 

0 

0 

same  time 

18 

9 

7 

21 

0 

2 

0 

0 

same  time 

20 

9 

7 

22 

2 

1 

0 

0 

same  time 

23 

9 

7 

23 

2 

0 

1 

0 

same  time 

25 

9 

8 

24 

2 

0 

0 

1 

same  time 

27 

10 

8 

25 

2 

0 

1 

0 

differ  time 

29 

10 

9 

26 

2 

1 

1 

1 

same  time 

32 

11 

10 

27 

2 

1 

1 

1 

differ  time 

35 

12 

11 

28 

0 

2 

0 

1 

same  time 

37 

13 

11 

29 

0 

2 

0 

1 

differ  time 

39 

14 

11 

30 

0 

0 

1 

1 

same  time 

39 

15 

12 

31 

0 

0 

1 

1 

differ  time 

39 

16 

13 

32 

2 

0 

0 

1 

same  time 

41 

17 

13 

33 

2 

0 

0 

1 

differ  time 

43 

18 

13 

totals 

27 

16 

13 

18 

Respond 

41 

2 

0 

0 

0 

single 

45 

18 

13 

42 

1 

1 

0 

0 

single 

47 

18 

13 

43 

1 

0 

1 

0 

single 

48 

18 

14 

44 

1 

0 

0 

1 

single 

49 

19 

14 

45 

2 

1 

0 

0 

same  time 

52 

19 

14 
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46 

2 

0 

1 

0 

same  time 

54 

19 

15 

47 

2 

0 

0 

1 

differ  time 

56 

20 

15 

48 

2 

0 

1 

0 

differ  time 

58 

20 

16 

49 

2 

1 

1 

1 

same  time 

61 

21 

17 

50 

2 

1 

1 

1 

differ  time 

64 

22 

18 

51 

1 

1 

0 

1 

same  time 

66 

23 

18 

52 

1 

1 

0 

1 

differ  time 

68 

24 

18 

60 

3 

0 

0 

0 

same  time 

71 

24 

18 

61 

1 

2 

0 

0 

same  time 

74 

24 

18 

62 

3 

1 

0 

0 

same  time 

78 

24 

18 

63 

3 

0 

1 

0 

same  time 

81 

24 

19 

64 

3 

0 

0 

1 

same  time 

84 

25 

19 

65 

3 

0 

1 

0 

differ  time 

87 

25 

20 

66 

3 

1 

1 

1 

same  time 

91 

26 

21 

67 

3 

1 

1 

1 

differ  time 

95 

27 

22 

68 

1 

2 

0 

1 

same  time 

98 

28 

22 

69 

1 

2 

0 

1 

differ  time 

101 

29 

22 

totals 

43 

15 

9 

11 

Math  TCI 

1 

0 

1 

2 

same  time 

102 

31 

23 

TC2 

1 

0 

1 

2 

same  time 

103 

33 

24 

TC3 

1 

0 

1 

2 

same  time 

104 

35 

25 

TC4 

1 

0 

1 

2 

same  time 

105 

37 

26 

TC5 

1 

0 

1 

2 

same  time 

106 

39 

27 

TC6 

1 

0 

1 

2 

same  time 

107 

41 

28 

TC7 

1 

0 

0 

2 

same  time 

108 

43 

28 

totals 

7 

0 

6 

14 

Notes:  8  -  Set  attenuation  message,  set  newattenuation  =  2 


10  -  Get  attenuation  message 

13  -  Increase  attenuation  message 

14  -  Decrease  attenuation  message 

23  -  INIT  control  message  sent;  OPTl  &  Ctrl  -  same  time  -  Passive:  downstream  received 
packets  =  214 

30  -  INIT  control  message  sent  -  Ctrl  &  ENV  -  same  time  -  Passive:  downstream  received 
packets  =  214 

63  -  INIT  control  message  sent  -  OPTl  &  Ctrl  -  same  time  -  Respond:  downstream  received 
packets  =  211 

65  -  Set  attenuation  message,  set  newattenuation  =  5 

67  -  INIT  control  message  sent  -  OPTl,  OPT2,  Ctrl  &  ENV  -  differ  time  -  Respond:  downstream 
received  packets  =  207 
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Appendix  I  -  Fixed  Optical  Attenuator  (FOA) 


LI  Device  Description: 

A  Fixed  Optical  Attenuator  (FOA)  is  one  of  the  most  basic  devices  used  in  fiber  optic 
systems.  The  FOA  is  used  to  attenuate  the  power  of  optical  signals  by  a  fixed  amount,  usually 
expressed  in  decibels  (dBs).  FOAs  may  be  fabricated  using  a  number  of  different  principles  in 
order  to  achieve  the  desired  attenuation.  FOAs  are  typically  fabricated  using  either  doped  fibers 
or  misaligned  splices  since  both  of  these  are  reliable  and  inexpensive,  /n/me-style  FOAs  are 
incorporated  into  patch  cables  at  the  time  of  manufacture  and  provide  a  convenient  means  of 
providing  a  desired  fixed  attenuation  in  a  fiber  link.  The  alternative  build  out-style  attenuator  is  a 
small  male-female  adapter  that  can  be  used  to  adjust  the  level  of  attenuation  by  coupling  one  or 
more  FOAs  between  fiber  cables.  In  some  cases  where  variable  amounts  of  optical  attenuation 
are  needed,  a  Variable  Optical  Attenuator  (VOA)  may  be  used  which  can  be  manually  or 
electrically  adjusted  to  achieve  the  desbed  attenuation  level.  Flowever,  for  purposes  of  this 
discussion  we  only  consider  FOAs.  See  Figure  1  for  an  example  of  a  FOA. 


Figure  75.  Fixed  Optical  Attenuator  (ThorLabs,  2013). 

The  FOA  is  perhaps  one  of  the  simplest  optical  devices  to  understand  and  behaviorally 

model.  For  this  reason,  we  now  present  the  explicit  modeling  of  a  fixed  optical  attenuator  as  a 
means  to  demonstrate  and  exercise  the  Discrete  Event  Simulation  Specification  (DEVS) 


formalism  used  to  represent  the  behavior  of  system  components.  Structurally,  the  FOA  is  a 
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bidirectional  optical  component  with  two  optical  ports.  Optical  signals  arriving  at  one  of  the 
ports  are  attenuated  by  a  fixed  amount  and  then  propagated  to  the  other  port  after  a  defined 
propagation  delay.  The  FOA  is  sensitive  to  the  power  of  the  optical  signals  that  are  propagated 
through  the  component.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold,  the  FOA 
may  become  permanently  damaged  which  changes  its  attenuation  characteristics.  Similarly,  the 
FOA  is  sensitive  to  the  temperature  in  the  environment  in  which  it  operates.  If  the  temperature 
exceeds  defined  thresholds,  the  FOA  may  become  temporarily  degraded  or  permanently 
damaged  which  changes  its  attenuation  characteristics.  If  temporarily  degraded,  the  device  may 
recover  to  normal  operating  behavior  after  the  temperature  returns  to  a  “normal”  operating 
temperature. 

The  first  step  involved  with  modeling  the  FOA  is  to  collect  and  understand  the  physical, 
behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this  information  was 
obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics.  The  SME 
developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica  software  program  that 
modeled  the  EOA.  The  SME  developed  a  series  of  use  cases  that  exercised  the  functionality  of 
the  device  over  a  wide  variety  of  conditions  and  verified  the  model  and  validated  the  input  and 
output  behavior  of  the  device  within  a  single  Mathematica  model  (worksheet).  The  Mathematica 
worksheet  served  as  the  primary  means  by  which  the  SME  communicated  the  behavior  of  the 
EOA  to  the  researcher. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  EOA  using 
the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated  to  the 
detailed  development  of  the  DEVS  model  of  the  EOA.  Once  developed,  the  model  will  be 
simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  in  the  Mathematica 
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worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that  the  DEVS 
formal  model  matehes  the  behavior  of  the  Mathematiea  model  and  henee  the  real  eomponent. 

Onee  eompleted,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
ereated  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
eonstruetion  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 


1  2 


Figure  76.  Symbol  for  Eixed  Optieal  Attenuator  (EGA)  in  the  QKD  system  arehiteeture. 

1.2  Fixed  Optical  Attenuator  (FOA)  Conceptual  Model 


Optlrii 


OptOut2 


OptOuti 


Figure  77.  Fixed  Optieal  Attenuator  (FOA)  eoneeptual  model. 


The  eoneeptual  model  for  a  FOA  eonsists  of  two  optieal  input  ports  {Optini,  OptIn2}, 
two  optieal  output  ports  {OptOuti,  OptOut2},  and  one  environmental  input  port  {Evnin}.  The 
environmental  port  allows  external  sourees  to  eommunieate  ehanges  in  the  operational 
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environment  to  the  FOA.  In  comparison  to  the  FOA  symbol  used  in  the  QKD  simulation 
architecture  shown  in  Fig.  1,  a  single  bidirectional  optical  connection  is  decomposed  into  an 
optical  input  and  an  optical  output  in  the  conceptual  model.  This  is  necessary  to  properly 
represent  the  behavior  of  the  device  using  the  DEVS  formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  FOA,  a  small  portion  of  the  signal  will 
be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model  decomposes 
each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  2  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  FOA  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to  determine 
if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is  made  when 
the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once  overpowered  the 
device  will  permanently  change  attenuation.  External  environmental  messages  sent  to  the  device 
convey  the  temperature  of  the  operational  environmental  so  the  EGA  can  determine  if  it  is 
degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In  either  case,  a  function 
determines  how  the  attenuation  changes  as  a  function  of  the  device  state  and  current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation. 
This  greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat 
multiple  optical  signals  as  independent  entities. 


307 


1.3  Mathematical  Model 


For  a  detailed  mathematieal  deseription  of  the  FOA,  refer  to  Seetion  7.8  whieh  contains  the 

Mathematica  worksheet  provided  by  the  optical  physics  SME. 

1.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the  EOA. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Place  the  optical  packet  into  the  queue 

•  Immediately  calculate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same 
port  number. 

•  Remove  the  packet  from  the  queue,  calculate  the  attenuated  output  optical  signal  based 
upon  the  input  optical  signal,  the  OverPower  flag,  the  OverTemp  flag,  and  the  current 
environment. 

•  Send  the  attenuated  output  signal  out  of  the  optical  output  port  number  that  is  not  the 
same  as  the  input  port  number. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 
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1.5  Phase  Transition  Diagram 


The  phase  transition  diagram  in  Fig.  3  shows  the  phases  of  the  attenuator  in  the  boxes  and 
the  transitions  represented  by  arrows  between  the  phases.  Eaeh  transition  is  labeled  with  the  type 
of  transition  (dext  -  external  or  dmt  -  internal)  and  the  signifieant  aetions  that  take  plaee  during  the 
transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value  of  the  time 
advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase  and  an  entry 
showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs.  Note  there  is 
a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the  attenuator  at 
the  same  time. 


1.6  Event-Trace  Diagram 

This  section  shows  various  examples  of  packets  entering  the  EOA.  The  tables  list  the 
states  the  attenuator  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
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variable,  current  temperature  of  the  attenuator,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes. 


Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Queue:  contents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 


1. 6. 1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  32.  Case  I  state  list. 


Notes: 
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1  packet,  0  environmental  events,  0  external  events 


I 

Figure  79.  Case  I  sequence  diagram. 


1.6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  33.  Case  II  state  list. 


Notes: 
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1  packet,  0  environmental  events,  1  external  event  (with  1  packet)  at  e=2 


Passive 

Reflect 

Respond 

1 

dext  optical  message 

1 

1 

1 

1 

1 

dint  optical  message 

1 

1 

dext  optical  message 

1 

1 

1 

1 

1 

dint  optical  message 

- ^ ► 

V 

r*n 

dint  optical 
message 


Figure  80.  Case  II  sequence  diagram. 


1.6.3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 

Table  34.  Case  III  state  list. 

Notes: 

entry/  store  over  over  interrupt  queue  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 
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Figure  81.  Case  III  sequence  diagram. 

1.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 


Table  35.  Case  IV state  list. 
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Figure  82.  Case  IV  sequence  diagram. 

1. 7  Fixed  Optical  Attenuator  (FOA)  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 
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•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 


For  the  fixed  attenuator  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  8 ext,  8i„t,  8con,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 
Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp]  is  the  set  of  output  ports  and  values; 
S  =  set  of  sequential  states; 

8ext  =  0  X  5  is  the  external  state  transition  function; 

8int  =  S'  ^  S'  is  the  internal  state  transition  function; 

8con  =  0  X  S  is  the  confluent  transition  function; 

/I  =  S  ^  T*  is  the  output  function; 

to  =  S  ^  U  00  or  S  ^  R  ,  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  to}^)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  attenuator  (Xm?  Tm?  S,  Sexti  8lnt,  8  con, 
where 


tp  =  transmission  time  inside  the  attenuator 
temperature  =  current  temperature  of  the  attenuator 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “reflect”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
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overpower  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  optieal  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  eurrent  optieal  paeket 
peak.power  =  variable  the  holds  the  peak  power  of  the  eurrent  optieal  paeket 
messagebag=  variable  that  stores  the  eurrent  x  input  value(s)  (p,v) 

damaged.power  =  variable  that  holds  the  eomponent  damaged  optieal  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 
reflect  =  variable  that  stores  the  current  reflected  optical  packet 
reflect.port  =  variable  that  holds  the  current  reflection  output  port 
reflect.power  =  variable  that  holds  the  current  reflection  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
queue.current  =  variable  that  holds  the  currently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
e  =  elapsed  time  since  last  transition  occurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  scheduled  inputs 
queue  sizeO  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_reflected()  =  method  returns  the  first  unrefiected  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refiected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
insert  event  qO  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  f{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  fcurrent.v,  temperature, 
overtemp,  peakpwr,  overpwr) 
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calcReflectedQ  =  method  that  calculates  reflection  power  of  an  optical  packet 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 

q.Vmm  =  minimum  value  in  the  queue 

v.q  =  value  from  a  queue  entry 

Every  Sext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Optini”,  “OptIn2”,  “Envin”}  with 

Xm  =  {(“Optini”,  Vopt),  (“OptIn2”,  Vopt),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 


OutPorts  =  {“OptOuti”,  “OptOut2”}  with 

Ym=  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  YoptOut2)}  is  the  set  of  output  ports  and  values. 

phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower  interruptRespond,  queue) 
{{“passive”,  “reflect”,  “respond”}  x  ExRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  V) 

External  Transition  Function: 

dextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((p;,v,),.. 

(Pn,Vn)))  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  over  power, interrupt  Respond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  E  {“Optlnf’,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrre«t) 
queue.current  =  queue_first(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “respond”  and  p  E  {‘‘Optlnf’,  “OptIn2”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_need_reflected() 
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reflect  =  {queue. current.p),  c&\cRs:^[QCiQd{queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  —  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time. delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

{phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn) 
otherwise; 

Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“refleef’,  0,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn)) 
if  phase  =  “refleet”  and  need.reflect  !=  null 
need.reflect  =  queue_need_refleeted() 
current  =  need.reflect 

reflect  =  {current.p),  ealeRefleeted(cMrrent.v)) 
mark_refleeted(cMrrent) 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “reflect”  and  need.reflect  =  null 
need.reflect  =  queue_need_reflected() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  calcAtten(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “Optini” 

outputPulse  =  calcAtten(cMrre«t.v,  temperature,  overtemp,  peakpwr,  overpwr) 
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outputPort  =  “OptOuti” 
timeLeftRespond  =  propagation  delay 
else 

time. delay  =  timeLeftRespond 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  ealeAtten(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  oalcAtten(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.xl.jcn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 
(reflect. p,  reflect. v) 
if  phase  =  “reflect” 

(output.port,  output.pulse) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  =  cr; 
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1.8  Mathematical  model 


Pulse  propagation  considerations  for  the  Fixed  Attenuator  Module 
within  the  QKD  OMNet++  simulation  environment 


The  fixed  optical  attenuator  is  a  device  wtticli  attenuates  the  output  optical  power. 


The  operational  characteristics  are  as  follows: 

•  light  ir^ut  to  port  1  will  exit  port  2 
-  light  input  to  port  2  will  exit  port  1 

The  only  significant  modilication  to  the  optical  message  will  be  the  amplitude  {power). 


Pulse  Characteristics  (e.g.) 

These  parameters  are  used  in  the  janes  representation  of  the  standard  coherent  pulse  optical 
message  packet. 


gtn 

. 


CQ&Q 

{sin  or)  s'*. 


Pertinent  Pulse  Characteristics  for  the  Fixed  Attenuator  Module 


Eol  C*  electric  field  input  into  port  1  *■) 

Eo2  electric  field  input  into  port  2  *} 

Optical  Specifications 

This  following  values  are  taken  (as  example}  from  Pacific  Interconnects  part  number  ATB«F  A  R  15  B 
(httpifwww.pacifidntercQ.CDnri/pdf/atlenuators/riber'-optic-fixed-anenualor.pdf) 

Attenuation.  :=  15  attenuation,  units  of  -dB  *) 

AttenuationAccuracy  t  =  0.1 

(*  Baximun  percentage  deviation  frost  "Attenaution'  value,  units  of  -dB  *) 
Returnlioss  £0  (*  typical  MniiniHn  return  loss,  units  of  -dB  t> 

TeopH  :=  75  (•  max  operational  temperature ,  units  of  °C 
TefflpL  ;=  -40  C*  it>r n  operational  temperature,  units  of  °C  •) 

HaxPwr  ;=  2000  (*  maxi  ririim  operational  power, 

units  of  (note;  value  assumed,  not  given  in  product  datasheet)  *] 


Alien  uaiion  Calculaiior^s 

Note  tiial  the  'AttsnualionAccuracy^  has  not  been  built  into  the  calculations  below.  This  variability  can 
be  built-in  upon  the  instantiation  of  a  fixed  attenuator  within  the  simulation. 

Eout2  [Einl_,  Atten_]  : »  Einl  *  V {*  case;  optical  input  on  port  1  *) 

EoutltEin2_,  Atten_]  Ein2  «  yj ease;  optical  input  on  port  2  *) 

If  we  wish  to  Hag  the  attenuator  to  include  undeslred  return  (reflected)  messapQes,  the  following  opera¬ 
tions  would  hold  true, 

EoutlHefleeted[Einl_,  RetDoss_J  :=  Elnl  *  yj 
Eout2Refleeted  [Ein2_,  RetLQaa_J  :=  Ein£  *  yj  in 
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Real-World  Example 


This  example  is  taken  from  Pacific  Interconnects  part  number  ATB-F  A  R  15  B 
(httpi/www.padfidnterco.com/pdf/attenuators/fiber-optic-fixed-atterHjator.pdf)  as  given  above. 

Eol  : >  1 
Eo2  : >  1 

Eoutl[Eol,  Att*nuati.on]  // N 
0.177828 

Eout2[Eo2.  Attenuation]  //  N 


0.177828 

EoutlRe£lected[Eol,  ReturnLosa]  // N 
0.001 

Eout2Ref lected [Eo2 ,  ReturnLoaa]  //  N 
0.001 

fOl  S  \S  chtitc  nolc»: 

hltp://MW«.paL1^lcmlc^;u.L'utn/aIh;nualur^k/tltll.‘T•up4K'•aBl.’nuaIor.hl^I 
hllp;//»  .liluttitK.cunVncwuTulippucV.clin  .’ufa}cct)(TiMjp_iil~t  3X5 

hllp:/A^w  «.□«;«  pun.cum/t  ucd-libt.‘r><)p(H:>AUL’niialutyX3567X/|033/inlu.aNpxfftab_urilcniiK> 
hllp;//wwr>»  .a/opliv'v.co«n/ALLNtW_PDl'A3 1  S0030.pill 


1.9  Component  Use  Case 


1.9.1  Respond  to  an  Optical  Packet  in  the  Fixed  Optical  Attenuator  (FOA) 

Optical  packet  arrives  at  the  FOA.  A  portion  of  optical  packet  reflects  back  down  incoming 
optical  line.  Plaee  the  optical  packet  into  the  optieal  queue.  Check  to  see  if  optical  packet 
overpowers  the  FOA.  Reeords  overpower  condition,  if  applicable.  Remove  the  optical  packet 
from  the  queue  and  caleulate  the  attenuated  optical  output  signal  based  on  the  input  signal  and 
the  eurrent  component  state.  Propagate  the  attenuated  optieal  output  signal  out  of  the  component 
optical  port  that  is  not  the  same  as  the  input  port. 


•  Identified  Alternative  Uses  Cases 

o  React  to  an  environmental  message 
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•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
o  Reflections  are  not  affected  by  component  state 
o  Incoming  electrical  signals  are  not  affected  by  component  state 


Initialization 

No  Optical  Output 


Normal  State 


•Reflections  are  not  configured  to  be  effected  by  state 
•Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  83.  Component  states. 


State  =  {phase,  o,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


ta=  time 
delay 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  84.  FOA  phase  transition  diagram. 
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1.9.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  reflected  properly. 

•  Optieal  paeket  entered  and  removed  from  queue  in  proper  sequenee. 

•  Overpower  eondition  properly  reeognized  and  recorded. 

•  Optieal  paeket  attenuated  properly  to  the  limit  of  aeeuraey. 

•  Optieal  packet  propagated  out  the  eorreet  port  at  the  eorrect  time. 

1.9.3  Respond  to  Optical  Packet  End  Goals 

•  Optieal  paeket  refleeted  properly. 

•  Optieal  paeket  entered  and  removed  from  queue  in  proper  sequenee. 

•  Overpower  eondition  properly  reeognized  and  reeorded. 

•  Optieal  paeket  attenuated  properly  to  the  limit  of  aeeuraey. 

•  Optical  packet  propagated  out  the  eorreet  port  at  the  eorrect  time. 

1.9.4  Respond  to  an  Environmental  Packet  in  the  Eixed  Optical  Attenuator  (EOA) 

Environmental  paeket  arrives  at  the  eomponent.  Cheek  to  see  if  environmental  paeket 
temperature  sets  the  eomponent  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level 
returns  eomponent  from  degraded  state  to  normal  state.  Reeords  ehange  in  eondition,  if 
applicable.  Change  eomponent  funetion  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

1. 9. 5  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  paeket  reeeived  properly 

•  Overtemperature  condition  properly  reeognized  and  reeorded 

•  Change  of  state  eompleted  and  reeorded  properly,  if  neeessary 

•  Change  eomponent  function  properly,  if  neeessary 

1. 10  Fixed  Attenuator  Test  Cases 

Eaeh  optieal  eomponent  was  tested  by  sending  inputs  into  the  eomponent,  eapturing  the 
output,  and  evaluating  the  output  line-by-line  to  eheek  behavior  and  timing.  Eaeh  eomponent  had 
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each  of  its  input  ports  (optical,  environmental  (env),  and/or  control  (ctrl))  tested  singly,  then  in 
different  combinations  of  ports  and  input  messages.  All  identified  errors  were  corrected  and  the 
component  retested  until  it  functioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  processing. 
Control  messages  work  in  the  same  way,  but  force  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 

Table  5.  Fixed  Attenuator  Test  Cases. 


Phase 

Case 

Inject  Ports 

Optl  Opt2 

Env 

Notes 

Running 

Totals 

opt  #  env  # 

Passive 

1 

1 

0 

0 

single 

1 

0 

2 

0 

1 

0 

single 

2 

0 

3 

0 

0 

1 

single 

2 

1 

4 

1 

1 

0 

same  time 

4 

1 
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5 

1 

1 

0 

differ  time 

6 

1 

6 

1 

1 

1 

same  time 

8 

2 

7 

1 

1 

1 

differ  time 

10 

3 

8 

0 

1 

1 

same  time 

11 

4 

9 

0 

1 

1 

differ  time 

12 

5 

10 

1 

0 

1 

same  time 

13 

6 

11 

1 

0 

1 

differ  time 

14 

7 

20 

2 

0 

0 

same  time 

16 

7 

21 

0 

2 

0 

same  time 

18 

7 

22 

2 

2 

0 

same  time 

22 

7 

23 

2 

2 

0 

differ  time 

26 

7 

24 

2 

2 

1 

same  time 

30 

8 

25 

2 

2 

1 

differ  time 

34 

9 

26 

0 

2 

1 

same  time 

36 

10 

27 

0 

2 

1 

differ  time 

38 

11 

28 

2 

0 

1 

same  time 

40 

12 

29 

2 

0 

1 

differ  time 

42 

13 

totals 

21 

21 

13 

42 

Respond 

41 

2 

0 

0 

single 

44 

13 

42 

0 

2 

0 

single 

46 

13 

43 

1 

0 

1 

single 

47 

14 

44 

2 

1 

0 

same  time 

50 

14 

45 

2 

1 

0 

differ  time 

53 

14 

46 

2 

1 

1 

same  time 

56 

15 

47 

2 

1 

1 

differ  time 

59 

16 

48 

0 

2 

1 

same  time 

61 

17 

49 

0 

2 

1 

differ  time 

63 

18 

50 

2 

0 

1 

same  time 

65 

19 

51 

2 

0 

1 

differ  time 

67 

20 

60 

3 

0 

0 

same  time 

70 

20 

61 

0 

3 

0 

same  time 

73 

20 

62 

3 

2 

0 

same  time 

78 

20 

63 

3 

2 

0 

differ  time 

83 

20 

64 

3 

2 

1 

same  time 

88 

21 

65 

3 

2 

1 

differ  time 

93 

22 

66 

0 

3 

1 

same  time 

96 

23 

67 

0 

3 

1 

differ  time 

99 

24 

68 

3 

0 

1 

same  time 

102 

25 

69 

3 

0 

1 

differ  time 

105 

26 

totals 

36 

27 

13 

63 

TCI 

1 

0 

2 

single 

106 

28 

TC2 

1 

0 

2 

single 

107 

30 

TC3 

1 

0 

2 

single 

108 

32 

326 


TC4 

1 

0 

2 

single 

109 

34 

TC5 

1 

0 

2 

single 

110 

36 

TC6 

1 

0 

2 

single 

111 

38 

TC7 

1 

0 

2 

single 

112 

40 

totals 

7 

0 

14 

21 
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Appendix  J  -  Half-Wave  Plate 


J.l  Device  Description: 

The  half-wave  plate  is  an  optical  device  that  transforms  the  input  wave  by  retarding  one 
of  the  components  of  the  wave.  The  “slow”  axis  is  retarded  by  some  amount  while  the  “fast”  axis 
has  a  very  small  reduction  in  its  transmission  velocity  through  the  device.  A  half  wave  plate  can 
be  used  to  rotate  the  polarization  of  linearly  polarized  light  with  very  little  loss  (Saleh  &  Teich, 
1991).  The  change  of  angle  is  twice  the  difference  of  input  angle  and  the  plate  angle  of  the  slow 
axis  but  note  that  if  the  incoming  linearly  polarized  light  falls  upon  either  principal  axis,  there  is 
no  change.  See  Figure  1  for  an  example  of  a  half-wave  plate. 


Figure  85.  View  of  a  zero-order  half-wave  plate  (Newport,  2013). 

A  typical  half-wave  plate  is  made  from  two  quarter-wave  plates  glued  together  with  a 
free-space  gap  between  them  and  mounted  into  some  type  of  stabilizing  housing.  Although  each 
quarter-wave  plate  changes  linearly  polarized  light  into  left  or  right-circular  light,  by  aligning  the 
fast  axis  of  one  quarter-wave  plate  with  the  slow-axis  of  the  second  pate,  the  resultant  is  light 
that  is  still  linearly  polarized,  but  with  a  new  polarization  angle.  The  air  gap  between  the  quarter- 
wave  plates  allows  for  higher  levels  of  optical  power  through  the  plates. 
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The  Half-wave  plate  is  a  bidireetional  optieal  eomponent  with  two  optieal  ports.  Optieal 
signals  arriving  at  the  input  port  are  propagated  to  the  other  port  after  a  defined  propagation 
delay  and  the  polarizing  material  is  sensitive  to  the  power  of  the  optieal  signals  that  are 
propagated  through  the  component.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold, 
the  Half-wave  plate  may  become  permanently  damaged  which  changes  its  propagation 
characteristics.  Similarly,  the  Half-wave  plate  is  sensitive  to  the  temperature  in  the  environment 
in  which  it  operates.  If  the  temperature  exceeds  defined  thresholds,  the  Half-wave  plate  may 
become  temporarily  degraded  or  permanently  damaged  which  changes  its  propagation 
characteristics.  If  temporarily  degraded,  the  device  may  recover  to  normal  operating  behavior 
after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  the  modeling  the  Half-wave  plate  is  to  collect  and  understand 
the  physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica  software 
program  that  modeled  the  Half-wave  plate.  The  SME  developed  a  series  of  use  cases  that 
exercised  the  functionality  of  the  device  over  a  wide  variety  of  conditions  and  verified  the  model 
and  validated  the  input  and  output  behavior  of  the  device  within  a  single  Mathematica  model 
(worksheet).  The  Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME 
communicated  the  behavior  of  the  Half-wave  plate  to  the  researcher.  Additional  information 
came  from  product  data  sheets  from  commercial  vendors  and  standard  texts  from  the  optical 
field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  Half-wave 
plate  using  the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated  to 
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the  detailed  development  of  the  DEVS  model  of  the  Half-wave  plate.  Onee  developed,  the 
model  will  be  simulated  using  the  MS4ME  simulator  using  the  same  uses  eases  defined  in  the 
Mathematiea  worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that 
the  DEVS  formal  model  matehes  the  behavior  of  the  Mathematiea  model  and  henee  the  real 
eomponent. 

Onee  eompleted,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
ereated  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
eonstruetion  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 

1  2 

Figure  86.  Symbol  for  the  half-wave  plate  in  the  QKD  system  arehiteeture. 

J.2  Half-wave  plate  Conceptual  Model 

Envin 

_ ▼ _ 

OptlD;^  OptOut, 

- ►  - ► 

Half-wave 

Plate 

< -  < - 

OptOuty  Optln2 

Figure  87.  Half-wave  plate  eoneeptual  model. 
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The  conceptual  model  for  a  Half-wave  plate  consists  of  two  optical  input  ports  {Optini, 
OptIn2},  two  optical  output  ports  {OptOuti,  OptOut2},  and  one  environmental  input  port 
{Evnin}.  The  environmental  port  allows  external  sources  to  communicate  changes  in  the 
operational  environment  to  the  Half-wave  plate.  In  comparison  to  the  Half-wave  plate  symbol 
used  in  the  QKD  simulation  architecture  shown  in  Figure  2,  a  single  bidirectional  optical 
connection  is  decomposed  into  an  optical  input  and  an  optical  output  in  the  conceptual  model. 
This  is  necessary  to  properly  represent  the  behavior  of  the  device  using  the  DEVS  formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  Half-wave  plate,  a  small  portion  of  the 
signal  will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  3  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  Half-wave  plate  calculates  changes  to  the  power,  the  amplitude,  ellipticity, 
polarization  and  phase  of  any  packet  coming  through  either  optical  port  after  a  time  equaling  the 
propagation  delay  of  the  module.  The  packet  is  calculated  at  full  power  minus  some  small 
amount  to  account  for  attenuation  through  the  device  and  retards  the  packet  along  the  “slow” 
axis  of  the  plate  to  some  accuracy,  dependent  on  the  design  of  the  plate. 

The  Half-wave  plate  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation.  External  environmental  messages 
sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the  Half-wave 
plate  can  determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent 
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condition).  In  either  ease,  a  function  determines  how  the  propagation  ehanges  as  a  function  of  the 
deviee  state  and  current  temperature. 

When  multiple  optieal  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interferenee  at  the  Single  Photon  Deteetor  (SPD)  deviees  in  the  QKD  system  simulation.  This 
greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 

J.3  Mathematical  Model 

For  a  detailed  mathematical  description  of  the  Half-wave  plate,  refer  to  Section  8.8  which 
contains  the  Mathematiea  worksheet  provided  by  the  optical  physics  SME. 

J.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the  Half¬ 
wave  plate. 


•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  whieh  indicates  if  the  deviee  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optieal  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  eleared. 

•  OverTemp  is  a  flag  whieh  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  whieh  exeeed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Place  the  optieal  paeket  into  the  queue 

•  Immediately  caleulate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same 
port  number. 
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•  Retrieve  the  input  optieal  signal  from  the  queue,  and  determine  the  input  port,  elliptieity, 
polarization,  and  overall  phase  of  the  signal. 

•  Update  the  values  of  the  input  optieal  signal  based  on  the  eharaeteristies  of  the  half-wave 
plate,  the  original  values  of  the  input  optieal  signal  and  the  eurrent  environment. 

•  Send  the  attenuated  output  signal  out  of  the  optieal  output  port  number  that  is  not  the 
same  as  the  input  port  number. 

When  an  environmental  message  arrives: 

•  Update  the  Current! emp  with  the  eurrent  temperature  eontained  in  the  environmental 
message. 

•  If  the  eurrent  temperature  exeeeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

J.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  Half-wave  plate  in  the 
boxes  and  the  transitions  represented  by  arrows  between  the  phases.  Eaeh  transition  is  labeled 
with  the  type  of  transition  {dext  -  external  or  di„t  -  internal)  and  the  signifieant  aetions  that  take 
plaee  during  the  transition.  Eaeh  are  has  an  entry  either  beneath  or  beside  the  are  indieating  the 
value  of  the  time  advance  funetion  for  the  next  phase.  Eaeh  box  is  labeled  with  the  name  of  the 
phase  and  an  entry  showing  either  no  lambda  output  funetion  for  that  phase  or  what  the  phase 
outputs.  Note  there  is  a  self-loop  transition  from  reflect  to  reflect  if  multiple  optieal  paekets 
arrive  at  the  Half-wave  plate  at  the  same  time. 
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state  =  {phase,  o,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 


Figure  88.  Half-wave  plate  phase  transition  diagram. 

J.6  Event-Trace  Diagram 

This  section  shows  various  examples  of  packets  entering  the  FOA.  The  tables  list  the 
states  the  attenuator  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  attenuator,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes. 


Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 
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•  Queue:  contents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 

J.  6.1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  36.  Case  I  state  list. 
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Figure  89.  Case  I  sequence  diagram. 

J.  6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  37.  Case  II  state  list. 

Notes: 
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Figure  91.  Case  III  sequence  diagram. 

J.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 


Table  39.  Case  IV state  list. 
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Figure  92.  Case  IV  sequence  diagram. 

J.  7  Half-wave  plate  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 
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•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  Half-wave  plate  we  define: 

Parallel-DEVS  atomic  M=  {Xm,  Ym,  S,  Sext,  Sm,  Scon,  to) 

Where: 

Xm  =  {{p,v)  I  p  G  InPorts,  v  G  Xp)  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp]  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  0  X  XIj  ^  5  is  the  external  state  transition  function; 

Sint  =  S  ^  S  is  the  internal  state  transition  function; 

Scon  =  2  X  Xh  ^  S'  is  the  confluent  transition  function; 

/I  =  S  ^  T*  is  the  output  function; 

to  =  S  ^  U  00  or  S  ^  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  to}^)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  Half-wave  plate  {Xmi  Ym>  S,  Sextt  Slnt^  Scorn  -^9 
where 

tp  =  transmission  time  inside  the  attenuator 
temperature  =  current  temperature  of  the  attenuator 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “reflect”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
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overpower  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  optieal  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  eurrent  optieal  paeket 
peak.power  =  variable  the  holds  the  peak  power  of  the  eurrent  optieal  paeket 
messagebag=  variable  that  stores  the  eurrent  x  input  value(s)  (p,v) 

damaged.power  =  variable  that  holds  the  eomponent  damaged  optieal  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 
reflect  =  variable  that  stores  the  current  reflected  optical  packet 
reflect.port  =  variable  that  holds  the  current  reflection  output  port 
reflect.power  =  variable  that  holds  the  current  reflection  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
queue.current  =  variable  that  holds  the  currently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
e  =  elapsed  time  since  last  transition  occurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  scheduled  inputs 
queue  sizeO  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_reflected()  =  method  returns  the  first  unrefiected  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refiected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
insert  event  qO  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  f{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  fcurrent.v,  temperature, 
overtemp,  peakpwr,  overpwr) 
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calcReflectedQ  =  method  that  calculates  reflection  power  of  an  optical  packet 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 

q.Vmm  =  minimum  value  in  the  queue 

v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 
InPorts  =  {“Optini”,  “OptIn2”,  “Envin”}  with 

Xm  =  {(“Optini”,  Vopt),  (“OptIn2”,  Vopt),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 
OutPorts  =  {“OptOuti”,  “OptOut2”}  with 

Ym=  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  Yoptouti)}  is  the  set  of  output  ports  and  values. 
phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower  interruptRespond,  queue) 
{{“passive”,  “reflect”,  “respond”}  x  ExRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  V) 

External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((p;,v,),.. 

{pn,Vn)))  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower, interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  E  {“Optini”,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrre«t) 
queue.current  =  queue_first(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “respond”  and  p  E  {‘‘Optlnf’,  “OptIn2”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
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queue. current  =  queue_need_reflected() 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 

mark_reflected(^MeMe.  current) 

interruptRespond=  “Y” 

timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  =G  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time,  delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

(phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x  \  ..xn) 
otherwise; 

Internal  Transition  Function: 

Sint(phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“refleef’,  0,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn)) 
if  phase  =  “refleet”  and  need.reflect  !=  null 
need.reflect  =  queue_need_reflected() 
current  =  need.reflect 

reflect  =  (current.p),  ealeRefleeted(cMrrent.v)) 
mark_refleeted(cMrrent) 

(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “reflect”  and  need.reflect  =  null 
need.reflect  =  queue_need_reflected() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  ca\c?o\av(current.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
if  InPort  =  “OptIn2” 
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outputPulse  =  calcVolax(current.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
timeLeftRespond  =  propagation  delay 
else 

time. delay  =  timeLeftRespond 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optini” 

outputPulse  =  calcPolar  (current.v,  temperature,  overtemp, peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  ca\c?o\ar{current.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.xl.jcn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  dexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 
{reflect.p,  reflect. v) 
if  phase  =  “reflect” 

(output.port,  output.pulse) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  =  cr; 
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J.8  Mathematical  Model 


Pulse  propagation  considerations  for  the  Half  Wave  Plate  Module 
within  the  QKD  OMNet++  simulation  environment 


The  function  of  a  half  wave  plate  is  to  introduce  a  (near)  lossless  n  phase  shift  between  the  compo¬ 
nents  of  the  light  which  are  passing  through  the  *fast*  and  'slow*  wave  plate  axes.  These  devices  can 
be  used  to  rotate  the  polarization  of  lirwar  light  ar>d  to  chartge  the  'handedness*  of  circularly  and  ellipti- 
cally  polarized  light.  Note  that  purely  aH-fiber  COTS  half  wave  plates  are  rK>t  available.  In  most  cases, 
the  utilization  of  a  half  wave  plate  requires  colhmation  and  launch  from  the  fiber  into  free-space.  pass- 
ir^  through  the  wave  plate,  followed  by  colection  and  focusing  onto  the  outgoing  fiber. 

For  this  module  we  will  refer  to  y  as  the  angle  of  the  wave  plate's  fast  axis  above  the  laboratory  positive 
horizontal  *x*  axis. 


The  operatior^l  characteristics  are  as  follows; 

•  light  input  to  port  1  will  exit  port  2 

•  light  input  to  port  2  will  exit  port  1 

Significant  nnodiricatiorts  to  the  optical  message  will  be  the  amplitude.  Eo  (power),  elipticity,  4,  the 
polarization,  a,  and  the  overall  phase,  a. 


Pulse  Characteristics 


These  pararrwters  are  used  in  the  Jones  representation  of  the  standard  coherent  pulse  optical 
message  packet 


Pertinent  Pulse  Characteristics  for  the  Half  Wave  Plate  Module 


Eo  :  electric  field  input  singal 
a  :  polarization  of  the  input  signal 
4 :  eiptictty  of  the  input  signal 
ft  ovearll  phase  of  the  input  sigrtal 

The  following  parameter  values  are  taken  from  the  COTS  (free-space)  polymer  film  half-wave 
plates  offered  by  the  Newport  corporation 

(http  ://www .  nxtbook.com/nxtbooksynewportcorp/re8ource201 1  /#/800). 


Retardation  a  (•  half  wave  plate  (A/2)  at  1550  nm  •) 
RetardatlonAeciiraey  :«  a / 175  (•  accuracy  of  the  retardation,  A/350  •) 
Inner tLoss  :>  0.25  (•  aaatieue  value, 

calctilated  frow  94%  Internal  transmittance,  units  -dB  *) 

RetLoss  25  (•  mnximiiin  relative  return  power 
(calculated  from  <0.5%  reflectance),  units  of  -dB  •) 

TeopH  :a  50  (•  aiax  operational  temperature,  units  of  ^  *) 

Tempi  :*  -20  (*  min  operational  teeperature,  units  of  "C  *) 

MaaPwr  :>  100  (*  mswiimtm  operational  power, 
units  of  oM.  Calculated  from  500nil/cm*  threshold  damage, 
asstimlng  Smra  beam  diameter  •) 

Attenuatkxi  Calculations  for  Half  Wave  Plate 


Simplistic  Examples  of  Calculatioris  for  Half  Wave  Plate  (nof  for  use  in  the  0MNet++  package) 
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Proper  Mathematical  Calculations  for  use  with  OMNet-)--^  Package 

Pleas*  imptement  the  following  calculations  for  polarization,  ellipticity,  and  overall  phase  In  the 
OMNet'f^  simulation  environment  (don't  use  the  calculatiorts  in  the  preceding  section) 


Note:  Refresh  system  kernel  before  using  the  following  calculations.  This  section  Is  nscessary 
and  raqulrad  for  using  the  axampla  In  tha  final  (Full  Exampla)  sactktn. 


The  output  form  of  Jthrough  (previous  section)  needs  to  be  expressed  in  a  manner  which  can  be 
passed  in  our  standard  optical  message,  namely  (tgix-  I  thank  Ramesh  for  valuable  help 

with  these  calculations.  The  general  form  of  the  output  vector  is. 


.1  flout 


p 

Q  e‘ 


where. 


PtT_.  a_.  ♦_] 


V 


2*2  Cos  [2  a]  Cos  (4  y]  *2  Cos[e]  Sin [2  a]  Sin [4  y] 


Q[y  •  a  ,  e  ]  :■  - -v/l  -  Cos  [2  a]  Cos  [4  y]  -  cos  [e]  Sin  [2  a]  Sin  [4 

“  "  "  VF  ^ 

Thus,  the  output  polarization.  Ogut-  is  simply 


ooutl(y_,  o_,  ♦_]  :«  ArcCos[P[y,  o,  «]  ] 
or,  equally, 


oout2[y_,  o_,  ♦_]  :«  ArcSln[Q[y,  a,  ♦] ) 

To  conform  to  using  only  one  vakie  for  the  ellipticity  in  the  polarization  state  let.  you  =  ^  -  A,  where 


Jl[y_,  a_,  ♦_)  :■  JlrcTsn| 
a[y_,  o_,  ♦_]  :■  ArcTsn| 


2Cos[|j  Sln^lj  Sln[a]  Sln[2  y] 

Cos  [2  y  -  a]  -  2  |sin|  j  j  I  Sln(a]  Sln[2  y] 


I 


-2  Cosj 

[?1H 

[?: 

1  sin  [a]  Cos  [2  y] 

1  /  /  r 

|sin[2y-a]  *2  |sin||||  Sln(a]  Cos[2y]| 


(*  Note; 


this  Is  where  the  cooplex  sero  occurs .  The  nusierstor  needs  to  be 
tr^ped  for  zero  to  nske  the  entire  srgusient  of  the  ArcTan  be  zero.  *) 


yout(y_,  a_,  ♦_]  :■  a[y,  a,  d]  -A(y,  o,  «] 
eout(e_,  y_,  a_,  *_]  :«e«A[y,  a,  d] 

Full  Example  of  an  Optical  Pulse  Passed  Through  the  Half  Wave  Plate 

Input  optical  parameters 
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Eln  :■  Eo  (•  Input  light  aoplituda,  ai^ltr«ry  •) 

etin  :■  1.2S  (*  input  light  polarization, 

cozrasponda  to  an  angle  of  71.6197  above  horizontal  •) 

4in  :■  jr/24  (•  input  light  elliptieity, 
corresponda  to  slightly  elliptical  light  •) 

Sin  :■  0  (•  input  light  overall  phase  •) 

Half  wave  plate  optical  parameters 

Insertloss  0.25  (•  intrinsic  optical  loss,  units  of  -dB  •) 

Yplate  n  /  i  {*  half  wave  plate  fast  axis  orientation, 
corresponds  to  45°  above  horizontal  *) 

Output  electric  field  amplitude: 

Eout  [Ein_]  ■  Ein  •  V  // H 

0.944061  Eo 

Output  polarization  (aout1  and  crout2  should  always  be  the  same): 

aoutl[vplate,  ain,  din] 
aout2[')rplate,  ain,  Sin] 

0.320796 

0.320796 

Output  elliptieity  and  overal  phase  (*  the  numbers  in  this  case  are  similar  because  yplate  =  idA.  yielding 
0  in  the  numerator  of  the  expression  for  6  *).  Note  that  the  elliptieity  is  equal  but  reversed  in  direction. 

youtlYplata,  ain,  din] 
eoutfSin,  vplata,  ain,  Sin] 

-0.1309 

0.1309 


The  form  of  the  output  optical  pulse  given  the  above  parameters  would  be. 


Eoutf" 


Cos  (aOUt) 
V  Sin  (aout) 


0.944061  Eo 


Cos(0.3207g6| 


^  Sin(0.320796| 


in  other  words. 


AmplitudeOut  = 
tjoOut  = 

(Out  = 

aOut  = 

SOut  = 


0.944061  *  Eo 
(join 

«ln+0.1309 

0.320796 

-0.1309 


COTS  W  dxule  noiec 

hllp:X(www.iixlbuoiL.C(in>(nxlbix>k'u'ik'upurlL'ur7>'rijaaii(cel01  l/WMOO 

hnpi/^tiediofutnitiaiB.walbzm.cacii/I’ukuuutiL'ni  >lljgluThniU|jt>AWatcl*lali^  (*  if  yuu  haw  cnathonaUca  uulalleiL  lim  (kmxutialKxi 
prqect  u  excdlenl 


bUp://ur'ww.ioi'icxiiniA(:wu:/ilsta/pdPc<l/(:(1Ub9/IVilSruEns%3Ut-'0(afl  U9W.p«lf' 
hllp:tfwww.aauf)lu=ixooi/ALLNhW_PW-/l}l'S0071pdl 
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J.9  Component  Use  Case 


J.9.1  Respond  to  an  Optical  Packet  in  the  Half-wave  Plate 

Optical  packet  arrives  at  half-wave  plate.  A  portion  of  optical  packet  reflects  back  down 
incoming  optical  line.  Place  the  optical  packet  into  the  optieal  queue.  Check  to  see  if  optical 
packet  overpowers  the  half-wave  plate.  Records  overpower  condition,  if  applicable.  Remove  the 
optical  packet  from  the  queue  and  caleulate  the  attenuated,  ehanged  optical  output  signal  based 
on  the  input  signal,  component  characteristics  and  the  current  eomponent  state.  Propagate  the 
attenuated  optical  output  signal  out  of  the  component  optical  port  that  is  not  the  same  as  the  input 


port. 


•  Identified  Alternative  Uses  Cases 

o  React  to  an  environmental  message 

•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
o  Reflections  are  not  affected  by  component  state 
o  Incoming  electrical  signals  are  not  affected  by  component  state 


Under  c 
temper 
power  t 


‘Reflections  are  not  configured  to  be  effected  by  state 
'Electrical  signals  are  not  configured  to  be  effected  by  state 
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Figure  93.  Component  states. 


state  =  {phase,  o,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  94.  Half-wave  plate  phase  transition  diagram. 

J.  9.2  Respond  to  Optical  Packet  End  Goals 

•  Optieal  paeket  refleeted  properly 

•  Optieal  packet  entered  and  removed  from  queue  in  proper  sequence 

•  Overpower  condition  properly  recognized  and  recorded 

•  Optical  packet  attenuated  properly  to  the  limit  of  accuracy 

•  Optical  packet  propagated  out  the  correct  port  at  the  correct  time 

J.  9.3  Respond  to  an  Environmental  Packet  in  the  Half-wave  Plate 

Environmental  packet  arrives  at  the  component.  Check  to  see  if  environmental  packet 
temperature  sets  the  component  to  degraded  or  damaged  state.  Check  to  see  if  temperature  level 
returns  component  from  degraded  state  to  normal  state.  Records  change  in  condition,  if 
applicable.  Change  component  function  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 
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J.  9. 4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 

•  Overtemperature  condition  properly  recognized  and  recorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

J.IO  Half-wave  Plate  Test  Cases. 

Each  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  check  behavior  and  timing.  Each  component  had 
each  of  its  input  ports  (optical,  environmental  (env),  and/or  control  (ctrl))  tested  singly,  then  in 
different  combinations  of  ports  and  input  messages.  All  identified  errors  were  corrected  and  the 
component  retested  until  it  functioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  processing. 
Control  messages  work  in  the  same  way,  but  force  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
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column  listing  the  number  of  math-speoifio  tests.  These  math  tests  were  ereated  by  the  optieal 
SME  to  exereise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  eode  for 
possible  future  work  in  eomparing  the  eoneeptual  models  to  the  qkdX  framework. 

Table  5.  Half-wave  Plate  Test  Cases. _ _ _ 


Running 

Inject  Ports 

Totals 

Phase 

Case 

Optl 

Opt2 

Env 

Notes 

opt  # 

env  # 

Passive 

1 

1 

0 

0 

single 

1 

0 

2 

0 

1 

0 

single 

2 

0 

3 

0 

0 

1 

single 

2 

1 

4 

1 

1 

0 

same  time 

4 

1 

5 

1 

1 

0 

differ  time 

6 

1 

6 

1 

1 

1 

same  time 

8 

2 

7 

1 

1 

1 

differ  time 

10 

3 

8 

0 

1 

1 

same  time 

11 

4 

9 

0 

1 

1 

differ  time 

12 

5 

10 

1 

0 

1 

same  time 

13 

6 

11 

1 

0 

1 

differ  time 

14 

7 

20 

2 

0 

0 

same  time 

16 

7 

21 

0 

2 

0 

same  time 

18 

7 

22 

2 

2 

0 

same  time 

22 

7 

23 

2 

2 

0 

differ  time 

26 

7 

24 

2 

2 

1 

same  time 

30 

8 

25 

2 

2 

1 

differ  time 

34 

9 

26 

0 

2 

1 

same  time 

36 

10 

27 

0 

2 

1 

differ  time 

38 

11 

28 

2 

0 

1 

same  time 

40 

12 

29 

2 

0 

1 

differ  time 

42 

13 

totals 

21 

21 

13 

42 

Respond 

41 

2 

0 

0 

single 

44 

13 

42 

0 

2 

0 

single 

46 

13 

43 

1 

0 

1 

single 

47 

14 

44 

2 

1 

0 

same  time 

50 

14 

45 

2 

1 

0 

differ  time 

53 

14 

46 

2 

1 

1 

same  time 

56 

15 

47 

2 

1 

1 

differ  time 

59 

16 

48 

0 

2 

1 

same  time 

61 

17 

49 

0 

2 

1 

differ  time 

63 

18 

50 

2 

0 

1 

same  time 

65 

19 

51 

2 

0 

1 

differ  time 

67 

20 
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60 

3 

0 

0 

same  time 

70 

20 

61 

0 

3 

0 

same  time 

73 

20 

62 

3 

2 

0 

same  time 

78 

20 

63 

3 

2 

0 

differ  time 

83 

20 

64 

3 

2 

1 

same  time 

88 

21 

65 

3 

2 

1 

differ  time 

93 

22 

66 

0 

3 

1 

same  time 

96 

23 

67 

0 

3 

1 

differ  time 

99 

24 

68 

3 

0 

1 

same  time 

102 

25 

69 

3 

0 

1 

differ  time 

105 

26 

totals 

36 

27 

13 

63 

TCI 

1 

0 

2 

single 

106 

28 

TC2 

1 

0 

2 

single 

107 

30 

TC3 

1 

0 

2 

single 

108 

32 

TC4 

1 

0 

2 

single 

109 

34 

TC5 

1 

0 

2 

single 

110 

36 

TC6 

1 

0 

2 

single 

111 

38 

TC7 

1 

0 

2 

single 

112 

40 

TC8 

1 

0 

2 

single 

113 

42 

totals 

8 

0 

16 

24 
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Appendix  K  -  In-Line  Polarizer 


K.l  Device  Description: 

The  in-line  polarizer  is  a  filter  that  allows  light  of  a  one  polarization  to  pass  while 
bloeking  light  that  is  orthogonal  to  the  passed  light.  It  can  convert  unpolarized  light  into 
polarized  light  or  filter  out  extraneous  polarization  angles  from  already  polarized  light.  The  type 
of  polarizer  used  in  QKD  devices  is  the  in-line  fiber  polarizer,  which  consists  of  housing 
containing  input  and  output  lenses  with  some  form  of  polarizing  medium  in  between.  See  Figure 
1  for  an  example  of  an  in-line  polarizer. 


Figure  95.  View  of  a  fiber  in-line  polarizer  (ThorLabs,  2013). 

The  In-line  polarizer  is  a  bidirectional  optical  component  with  two  optical  ports.  Optical 
signals  arriving  at  the  input  port  are  propagated  to  the  other  port  after  a  defined  propagation 
delay  and  the  polarizing  material  is  sensitive  to  the  power  of  the  optical  signals  that  are 
propagated  through  the  component.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold, 
the  In-line  polarizer  may  become  permanently  damaged  which  changes  its  propagation 
characteristics.  Similarly,  the  In-line  polarizer  is  sensitive  to  the  temperature  in  the  environment 
in  which  it  operates.  If  the  temperature  exceeds  defined  thresholds,  the  In-line  polarizer  may 
become  temporarily  degraded  or  permanently  damaged  which  changes  its  propagation 
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characteristics.  If  temporarily  degraded,  the  device  may  reeover  to  normal  operating  behavior 
after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  the  modeling  the  In-line  polarizer  is  to  colleet  and  understand 
the  physieal,  behavioral,  and  performance  eharaeteristies  of  the  eomponent.  In  this  ease,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  detailed  mathematieal  model  in  the  Wolfram  Mathematiea  software 
program  that  modeled  the  In-line  polarizer.  The  SME  developed  a  series  of  use  cases  that 
exereised  the  functionality  of  the  device  over  a  wide  variety  of  eonditions  and  verified  the  model 
and  validated  the  input  and  output  behavior  of  the  device  within  a  single  Mathematiea  model 
(worksheet).  The  Mathematiea  worksheet  served  as  the  primary  means  by  whieh  the  SME 
eommunicated  the  behavior  of  the  In-line  polarizer  to  the  researeher.  Additional  information 
eame  from  produet  data  sheets  from  commereial  vendors  and  standard  texts  from  the  optieal 
field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  coneeptual  model  of  the  In-line 
polarizer  using  the  DEVS  formalism.  The  bulk  of  the  doeument  following  this  section  is 
dedicated  to  the  detailed  development  of  the  DEVS  model  of  the  In-line  polarizer.  Onee 
developed,  the  model  will  be  simulated  using  the  MS4ME  simulator  using  the  same  uses  cases 
defined  in  the  Mathematiea  worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output 
to  verify  that  the  DEVS  formal  model  matches  the  behavior  of  the  Mathematiea  model  and  hence 
the  real  component. 

Onee  eompleted,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construetion  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
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timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 


Figure  96.  Symbol  for  the  In-line  polarizer  in  the  QKD  system  architeeture. 


K.2  In-line  polarizer  Conceptual  Model 
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Figure  97.  In-line  polarizer  conceptual  model. 


The  conceptual  model  for  an  In-line  polarizer  consists  of  two  optical  input  ports  {Optini, 
Optini},  two  optical  output  ports  {OptOuti,  OptOut2},  and  one  environmental  input  port 
{Evnin}.  The  environmental  port  allows  external  sources  to  communicate  changes  in  the 
operational  environment  to  the  In-line  polarizer.  In  comparison  to  the  In-line  polarizer  symbol 
used  in  the  QKD  simulation  architecture  shown  in  Eigure  2,  a  single  bidirectional  optical 
connection  is  decomposed  into  an  optical  input  and  an  optical  output  in  the  conceptual  model. 
This  is  necessary  to  properly  represent  the  behavior  of  the  device  using  the  DEVS  formalism. 
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When  an  optical  signal  is  sent  to  the  input  of  the  In-line  polarizer,  a  small  portion  of  the 
signal  will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  3  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  In-line  polarizer  calculates  changes  to  the  power,  the  amplitude,  ellipticity  and 
polarization  of  any  packet  coming  through  either  optical  port  after  a  time  equaling  the 
propagation  delay  of  the  module.  The  packet  is  calculated  at  full  power  minus  some  small 
amount  to  account  for  attenuation  through  the  device  but  heavily  attenuates  any  packet  that  does 
not  match  the  polarization  of  the  polarizer.  Even  though  the  in-line  polarizer  is  meant  to  block 
light  that  does  not  match  its  polarization,  a  small  amount  of  light  that  nearly  matches  the 
polarization  of  the  polarizer  will  make  it  through  the  device  and  out  the  input  port. 

The  In-line  polarizer  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation.  External  environmental  messages 
sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the  In-line 
polarizer  can  determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent 
condition).  In  either  case,  a  function  determines  how  the  propagation  changes  as  a  function  of  the 
device  state  and  current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation.  This 
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greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 

K.3  Mathematical  Model 

For  a  detailed  mathematical  description  of  the  In-line  polarizer,  refer  to  Section  9.8  which 
contains  the  Mathematica  worksheet  provided  by  the  optical  physics  SME. 

K.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the  In¬ 
line  polarizer. 


•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Determine  the  input  port  number. 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Immediately  calculate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same 
port  number. 

•  Place  the  optical  packet  into  the  queue 

•  After  the  propagation  time  has  elapsed,  retrieve  the  input  optical  signal  from  the  queue, 
and  determine  the  input  port  and  polarization  of  the  signal. 

•  Update  the  values  of  the  input  optical  signal  based  on  the  characteristics  of  the  polarizer, 
the  original  values  of  the  input  optical  signal  and  the  current  environment. 

•  Send  the  attenuated  output  signal  out  of  the  optical  output  port  number  that  is  not  the 
same  as  the  input  port  number. 

When  an  environmental  message  arrives: 
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•  Update  the  Current! emp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

K.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  In-line  polarizer  in  the 
boxes  and  the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled 
with  the  type  of  transition  (dex/  -  external  or  dint  -  internal)  and  the  significant  actions  that  take 
place  during  the  transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the 
value  of  the  time  advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the 
phase  and  an  entry  showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase 
outputs.  Note  there  is  a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets 
arrive  at  the  In-line  polarizer  at  the  same  time. 
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K.  6  Event-Trace  Diagram 


This  section  shows  various  examples  of  packets  entering  the  FOA.  The  tables  list  the 
states  the  attenuator  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  attenuator,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes. 


Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Queue:  contents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 


K.  6. 1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  40.  Case  I  state  list. 
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Figure  99.  Case  I  sequence  diagram. 


K.  6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  41.  Case  II  state  list. 

Notes: 
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Figure  100.  Case  II  sequence  diagram. 


K.6.3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 

Table  42.  Case  III  state  list. 

Notes: 

entry/  store  over  over  interrupt  queue  assume 
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Figure  101.  Case  III  sequence  diagram. 

K.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 


Table  43.  Case  IV state  list. 
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Figure  102.  Case  IV  sequence  diagram. 

K.  7  In-line  polarizer  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 
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•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 


For  the  In-line  polarizer  we  define: 

Parallel-DEVS  atomic  M=  {Xm,  Ym,  S,  dext,  Sint,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  P  £  InPorts,  v  G  Xp)  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp]  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  2  X  XIj  — 5  is  the  external  state  transition  function; 

Sint  =  S'  ^  S'  is  the  internal  state  transition  function; 

Scon  =  0  X  S  is  the  confluent  transition  function; 

=  S  ^  T*  is  the  output  function; 
to  =  S  ^  U  00  or  S  ^  S  4  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  to}^)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  In-line  polarizer  (X/jf,  Tm,  S,  Sextt  Sint,  Scon,  tO) 

where 

tp  =  transmission  time  inside  the  attenuator 

temperature  =  current  temperature  of  the  attenuator 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 

phase  =  (“passive”,  “reflect”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
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interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  eurrent  optieal  paeket 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optical  packet 
messagebag=  variable  that  stores  the  current  x  input  value(s)  (p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optical  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 
reflect  =  variable  that  stores  the  current  reflected  optical  packet 
reflect.port  =  variable  that  holds  the  current  reflection  output  port 
reflect.power  =  variable  that  holds  the  current  reflection  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
queue.current  =  variable  that  holds  the  currently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
e  =  elapsed  time  since  last  transition  occurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  scheduled  inputs 
queue_size()  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_reflected()  =  method  returns  the  first  unrefiected  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refiected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update_delay()  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
insert  event  qO  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  f{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  /{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  fcurrent.v,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReflectedO  =  method  that  calculates  reflection  power  of  an  optical  packet 
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MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 
q.v  =  pointer  to  a  value  in  the  queue 
q.Vmm  =  minimum  value  in  the  queue 
v.q  =  value  from  a  queue  entry 

Every  Sext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Optini”,  “OptIn2”,  “Envin”}  with 

Xm  =  {(“Optini”,  Vopt),  (“OptIn2”,  Vopt),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 
OutPorts  =  {“OptOuti”,  “OptOut2”}  with 

Em=  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  Yoptouti)}  is  the  set  of  output  ports  and  values. 
phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower  interruptRespond,  queue) 
{{“passive”,  “reflect”,  “respond”}  x  VxRx{“Y’\  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  F} 

External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((p„v,),.. 

iPn,Vn)))  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower, interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  E  {“Optini”,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_first(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “respond”  and  p  E  {“Optini”,  “OptIn2”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_need_reflected() 
reflect  =  (queue. current.p),  cadcRedQCiQd(queue.current.v)) 
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mark_reflected(^Mewe.  current) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interrupt  Respond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag. temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interrupt  Respond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time_delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

{phase,  a-e,  store,  temperature,  overtemp,  overpower,  interrupt  Respond,  queue. x\..xn) 
otherwise; 

Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“reflecf’,  0,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn)) 
if  phase  =  “refleet”  and  need.reflect  !=  null 
need.reflect  =  queue_need_reflected() 
current  =  need.reflect 

reflect  =  (current.p),  ealcReflected(cMrrent.v)) 
mark_reflected(cMrrent) 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “reflect”  and  need.reflect  =  null 
need.reflect  =  queue_need_reflected() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  calcAtten(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcAtten(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
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timeLeftRespond  =  propagation  delay 
else 

time. delay  =  timeLeftRespond 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optini” 

outputPulse  =  calcPolar(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcPolar(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.xl.jcn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

Confluence  Function: 


dconis,  ta{s),  x)  =  Sext{Sint{s),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 
{reflect. p,  reflect. v) 
if  phase  =  “reflect” 

(output.port,  output.pulse) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  =  cr; 
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K.8  Appendix  A  -  Mathematical  model 


Pulse  propagation  considerations  for  the  In-line  Polarizer  Module 
within  the  QKD  OMNet-t-'f  simulation  environment 

Th6  in-line  fiber  polarizer  is  designed  to  pass  one  polarization  of  light  while  blocking,  with  significant 
extincttan.  light  with  a  polarization  orthogonal  to  that  of  the  passed  polarization.  This  design  can  be 
used  to  convert  unpolarized  (or  any  random  polarization  or  ellpticity)  into  highly  polarized  light.  It  can 
also  be  used  to  increase  the  extinction  ratio  of  polarized  signals.  Note  that  COTS  devices  are  available 
with  either  polarization-maintaining  or  single-mode  fiber  pigtails.  In  the  case  of  potarizalion-maintaining 
fiber,  the  polarizing  angle  (y)  will  be  aligned  with  one  of  the  two  guiding  axes  of  the  fiber.  For  single- 
mods  fiber  there  is  no  preffsred  axis  of  transmission  as  it  is  (ideaHy)  cylirvdricaly  symmetric.  Thus,  for 
the  single-mode  case,  we  will  refer  to  y  as  the  angle  above  the  laboratory  positive  horizontal  (x)  axis. 

The  operational  characteristics  are  as  foiows: 

-  light  input  to  port  1  will  exit  port  2 

-  light  input  to  port  1  will  exit  port  1 

Significant  modifications  to  the  optical  message  will  be  the  amplitude.  Eo  (power),  eliptldty,  and  the 
polarization,  a. 

Pulse  Characteristics  (e.g.) 

These  parameters  are  used  in  the  )ones  representation  of  the  standard  coherent  pulse  optical 
message  packet. 

■  (e;  I 

Pertinent  Pulse  Characteristics  for  the  In-Line  Polarizer  Module 

Eo  !  electric  field  input  singal,  port  1 
o  :  polarization  of  the  ir^ut  signal,  port  1 
:  elipticity  of  the  input  signal,  port  1 

The  following  parameter  values  are  examples  of  typical  Isolators  and  are  taken  from  COTS 
devices  offered  by  the  Newport  corporation  (htlp:/fwww.newport.oom/Flber-Optic-ln-Llne-Polarjz- 
erBf849607/10^yinfo.aspx#tab_Speclf{catlons).  Note  that  I  have  use  the  single-mode  liber  pig- 
tailed  version's  parameters. 

E:xtlnctlaiilla.le  ;>  40  typical  celative  power 
ealtted  froet  the  uodesired  polarization,,  units  of  -dB 
Inaertljoaa  D.5  {*  maxlmluB  power  loaa  given  an  insertion 
polarization  on  the  preffered  axis,  unite  -dB  *) 

RetLoss  55  (*  fflaxiitLum  relative  return  power,, 
signal  reflected  ^  an  input  beam,  units  of  -dB  *) 

TespH  70  (»  max  operatituial  temperature,  units  of  °C  *) 

Tempi.  0  (*  min  operational  temperature,  units  of  "C 
HaxPwr  :=  30D  (•  maximum  operational  power,  units  of  mH  •) 

Amplitude  Attenuation  Calculations  for  In-Line  Polarizer 

Potarizabon-basad  attenuation  must  be  included  in  the  calculabon.  Let's  first  define  our  optical  vector, 
as  it  wil  be  used  to  iMustraie  a  few  examples; 
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OptVect  :» 


Cea [a] 

.  Sixit“J  *** 


Hera.  4  is  the  irput  amplitiude,  a  is  the  potarization.  artd  is  the  elliptidty. 


For  the  case  of  single^nnode  fiber  pigtails  we  use  the  horizontal  tab  frame  as  y=0  (vertical  as  r=^/2). 
where  y  can  be  an/  value  [0  :  jt/2).  For  the  case  of  polarization-maintaining  fiber  pigtails.  /  wil  have  the 
values  of  only  0  or  n/2.  In  either  case,  the  tranformation  matrix  is. 


Pelarliejc  ('/_] 


/  (Cos[ir])^  (Ceatrl  *Siii[r]) 
Uc*s[v]  *SLa[v])  (SlafrlJ* 


To  calculate  the  output  amplitude  we  first  want  to  account  for  the  insertion  loss 
Eteaip  [A«plituile_j  iii*ertioJiLoaa_]  ;  >  Aaplitudi*  * 

Here  we  use  the  aforementioned  insertion  loss  of  -0.5  dB  and  the  input  amplitude  Eo 

EAZterliuertliOas  >  InaertlAsaJ 

0.444061  A 

We  now  have  to  calculate  the  effective  amplitude  of  the  electric  field  after  the  light  has  passed  through 
the  polarizer.  This  is  accomplished  by  taking  the  norm  of  the  vector  produced  by  operating  the  polariza¬ 
tion  matrix  on  the  optical  vector; 

Eouttir_]  «  Norm  [Polarizer  [y1 -PptVectJ  // E^lllSi■pll£y 
Ab3[co3(a]  Coaly]  »  Slnfa]  sin(y)  ]  A  Conjugate  [A]  Co3h[2  l*[y]  ] 

If  we  wish  to  flag  the  attenuator  to  include  undesired  return  (reflected)  messages,  the  following  opera¬ 
tions  would  hold  true, 

Eout[Elii_,  RetLa3a_]  :=  ELn  *  V 

Examples  For  Amplitude  Attenuation  in  the  In-Line  Polarizer 

As  an  example,  lets  take  the  polarizer  and  input  polarization  to  be  oriented  in  the  same,  positive  diago¬ 
nal  (4S“)  with  no  elipticity; 

r"i  ” 

Eout|^-|  Fullsmplify 

AbS  [A] 

As  it  should  be.  the  only  loss  in  Ihe  first  example  is  due  to  insertion  loss,  which  is  not  included  here  for 
ilustrative  purposes.  To  indude  insertion  loss,  simply  define  the  amplitude  A  to  be  EAftertnsenLoss, 
i.e.. 
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r  jf  1  JT 

Eout  -  —  /  EAIttrlnfttJctLaaa  f(  Tul  iSia^sllf  y 

4 

a.d440£l  At]a(A] 

As  a  second  example,  again  excluding  insertion  loss,  let' s  keep  the  potarizer  and  input  polarization  at 
the  same  angle,  but  make  the  light  circular  [a  =  a/4.  ^  =  a/2).  Insertion  loss  is  not  included  hereafter  for 
the  sake  of  darity; 

r  w.  Ji  n 

Eout  -  /.at  —  FullSinplify  //  N 

I-  4  i  4  2 

0.707107  Aba  (A) 

Because  the  polarization  'rotates',  a  power  factor  of  1/2  wlH  be  lost  ( 1/ '/Y in  the  amplitude).  Because 
the  light  is  circular,  the  orientation  of  the  polarizer  wont  effect  the  output  amplitude,  euen  if  perpendicu- 
lar  to  the  initial  Inp  ut  'polarization*. 

,  3  ji  ,  n  n 

Eout  -  /.a-»-/.  *-»-//  FuliSiinplify  //  H 

■-  4  4  i 

0.707107  Ab£(A] 

The  same  doesnt  hold  true  for  ellipticaHy  polarized  light.  In  the  plot  below,  I  change  a  to  making  the 
light  slightly  elliptical.  1  vary  the  polarizer  angle  y  horn  0  to  a: 

p  J»  JF 

Plot  EouttyJ  f .  a  -*  — /.  (t-F  —  /  .A-*l,  (If,  0,  JT} ,  FjcMie  -»■  Tjcme, 

L  3  4 

PlatR&nge -F  (0,  1},  FjcameLAtel -f  C" y" ,  "E<Mit  (UBits  at  A}~}j 


This  plot  Is  fun  to  play  wllh.  Note  what  happens  when  you  have  drcular  light  (o=a/4,  ^a/2).  linear  light 
=  any  artgle.  ^  =  0)  or  any  elliptical  light  (vary  a  or 

As  a  final  example,  let's  put  the  polarizer  angle  at  horizontal  (y  =  0).  but  change  the  Input  polarization  to 
vertical,  with  no  elkpticity 


Eout  [0]  /.  o-F  -  /.e-FO//  FullSiafjllZy 
2 
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This  is  idealized,  as  the  devices  typicaly  call  for  an  extinction  ralios  of  -30  to  -40  dB. 

Polarizaion  Calculadons  for  In-Line  Polarizer 

In  ail  cases,  Ihe  light  exiting  the  polarizer  will  be  nearly  pure  (within  the  tolerances  set  by  the  extinction 
ratio)  in  the  axis,  y,  of  the  polarizer.  Thus,  for  all  cases. 

OutpuCPol  :  E  y 


Final  Example  for  an  optical  pulse  passed  through  the  In-Line  Polarizer  (refresh  Kernel  before  use) 
lnsertL03.s  :>  0.5 

Cos [a] 


*1  (  Cofl  a] 

Optveetra  ,*  ]  ;= 

^  I  ,SJLn[a)e*V 


Polariiejc  t'ir_J  -  = 


/  (CoatrJ)'' 

[  (C0B[yJ  »Sin[yJ) 


(Coaiy]  .Sinlr]) 
(Sin[T])* 


Eout[y_,  a_,  #_]  *  •>/  *  Harm  (Polarizer  (t]  .OptVtct[a,  ♦])  f(  FullSlmplify 

0.  ftta  [cos  [q]  Co3  [y]  »***Siii(£i]  Sin[y]]  ■.,/ A  Conjugate  [A]  Co3h[Zlm[y]l 

In  the  example  below,  I  have  assigned  the  polarizer  angle  to  be  just  above  horizontal  (y  =  with  the 
light  polarized  at  positive  diagonal  (a  =  with  a  slight  eflipticity  (^  =  x/32) 

P  JT  Jt  rr  , 

OutputAaplitiuie  =  Eout^,  — ,  ^  FuliSlraplify 

lie  a  32 J 

0.794  435  AOb  [A] 


R 

OutputPolAriztian  s  — 

19 

n 

16 

OutputEllipticity  «  0 
0 


The  form  of  the  output  optical  pulse  given  Ihe  above  parameters  would  be. 


E(t)  =  f  1  =  OutpuAmplitude  e'**  V® 
t  )  Sii 


Cos  (Ou  putPolarization) 

Sin  (OutputPolarization}  e*  »Ou‘i=‘J'£iMcny 


{ ~  (  Cos[r/16]  1 


E(t) 

E(t)  =  (  ^^  )  =  0.784435*A*( 


•( 


0.980785 ' 
0.19509 


in  other  words, 

AmplitudeOut  =  0.7B4435  *  Amplitudelrv 

ijoOut  =  iiXiln 
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#OLit  =  flin 

aOlft  =  ;r/16 

<ACXJl  =  0 

CUIX  Wdbiii!ir  nuLci: 

Mtp:/fww'A.rKVrpurLcofQlVibcT-Op(K:-lD-LicH.'«Pubnxcn/M'M>4>7/]031/mib.itMpA#l^_Spt'i:incaitH:ti!i 

Mtpjrw*wjuajpLiL-s.L-ui^ALLNtV^_PDWmSOUlK.pJI‘ 


K.9  Component  Use  Case 


K.9.1  Respond  to  an  Optical  Packet  in  the  Inline  Polarizer 

Optical  packet  arrives  at  the  inline  polarizer.  A  portion  of  optieal  paeket  reflects  back  down 
incoming  optical  line.  Plaee  the  optieal  paeket  into  the  optieal  queue.  Cheek  to  see  if  optieal 
paeket  overpowers  the  inline  polarizer.  Reeords  overpower  eondition,  if  applieable.  Remove  the 
optieal  paeket  from  the  queue  and  ealeulate  the  attenuated  and  polarized  optieal  output  signal 
based  on  the  input  signal,  eomponent  charaeteristics  and  the  eurrent  eomponent  state.  Propagate 
the  attenuated  optieal  output  signal  out  of  the  eomponent  optieal  port  that  is  not  the  same  as  the 
input  port. 


•  Identified  Alternative  Uses  Cases 

o  Reaet  to  an  environmental  message 

•  Assumptions 

o  Component  has  completed  initialization  sequenee  at  least  onee 
o  Refieetions  are  not  affeeted  by  component  state 
o  Ineoming  eleetrical  signals  are  not  affected  by  eomponent  state 
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Initialization 

No  Optical  Output 


ormal  Stal 

pected  Optic 

L 

Output 

Under  degraded 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


Degraded  State 

Reduced  Optical 
Output 


Over  damaged 
temperature  or 
power  threshold 


Damaged  State 

No  Optical  Output 


Over  damaged 
temperature  or 
power  threshold 


•Reflections  are  not  configured  to  be  effected  by  state 
•Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  103.  Component  states. 


state  =  {phase,  a,  store,  temperature,  overtemp,  overpow/er,  interruptRespond,  queue. xl..xn} 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  104.  In-line  polarizer  phase  transition  diagram. 

K.  9.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  reflected  properly 

•  Optical  packet  entered  and  removed  from  queue  in  proper  sequence 

•  Overpower  condition  properly  recognized  and  recorded 

•  Optical  packet  attenuated  properly  to  the  limit  of  accuracy 
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•  Optical  packet  propagated  out  the  eorrect  port  at  the  eorrect  time 

K,9,3  Respond  to  an  Environmental  Packet  in  the  In-line  Polarizer 

Environmental  packet  arrives  at  the  component.  Check  to  see  if  environmental  packet 
temperature  sets  the  eomponent  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level 
returns  component  from  degraded  state  to  normal  state.  Records  change  in  condition,  if 
applicable.  Change  component  function  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

K.  9. 4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  reeeived  properly 

•  Overtemperature  eondition  properly  reeognized  and  reeorded 

•  Change  of  state  completed  and  reeorded  properly,  if  neeessary 

•  Change  eomponent  function  properly,  if  necessary 

K.IO  Inline  Polarizer  Test  Cases 

Eaeh  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  cheek  behavior  and  timing.  Eaeh  component  had 
each  of  its  input  ports  (optical,  environmental  (env),  and/or  eontrol  (ctrl))  tested  singly,  then  in 
different  eombinations  of  ports  and  input  messages.  All  identified  errors  were  eorrected  and  the 
eomponent  retested  until  it  functioned  properly  for  eaeh  test  ease. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  eomponent  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  proeessing. 
Control  messages  work  in  the  same  way,  but  foree  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  foree  an  immediate  response  to  the  change 
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in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 

Table  5.  Inline  Polarizer  Test  Cases. 


Phase 

Case 

Inject  Ports 

Optl  Opt2 

Env 

Notes 

Running  Totals 

opt  #  env  # 

Passive 

1 

1 

0 

0 

single 

1 

0 

2 

0 

1 

0 

single 

2 

0 

3 

0 

0 

1 

single 

2 

1 

4 

1 

1 

0 

same  time 

4 

1 

5 

1 

1 

0 

differ  time 

6 

1 

6 

1 

1 

1 

same  time 

8 

2 

7 

1 

1 

1 

differ  time 

10 

3 

8 

0 

1 

1 

same  time 

11 

4 

9 

0 

1 

1 

differ  time 

12 

5 

10 

1 

0 

1 

same  time 

13 

6 

11 

1 

0 

1 

differ  time 

14 

7 

20 

2 

0 

0 

same  time 

16 

7 

21 

0 

2 

0 

same  time 

18 

7 

22 

2 

2 

0 

same  time 

22 

7 

23 

2 

2 

0 

differ  time 

26 

7 

24 

2 

2 

1 

same  time 

30 

8 

25 

2 

2 

1 

differ  time 

34 

9 

26 

0 

2 

1 

same  time 

36 

10 

27 

0 

2 

1 

differ  time 

38 

11 
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28 

2 

0 

1 

same  time 

40 

12 

29 

2 

0 

1 

differ  time 

42 

13 

totals 

21 

21 

13 

42 

Respond 

41 

2 

0 

0 

single 

44 

13 

42 

0 

2 

0 

single 

46 

13 

43 

1 

0 

1 

single 

47 

14 

44 

2 

1 

0 

same  time 

50 

14 

45 

2 

1 

0 

differ  time 

53 

14 

46 

2 

1 

1 

same  time 

56 

15 

47 

2 

1 

1 

differ  time 

59 

16 

48 

0 

2 

1 

same  time 

61 

17 

49 

0 

2 

1 

differ  time 

63 

18 

50 

2 

0 

1 

same  time 

65 

19 

51 

2 

0 

1 

differ  time 

67 

20 

60 

3 

0 

0 

same  time 

70 

20 

61 

0 

3 

0 

same  time 

73 

20 

62 

3 

2 

0 

same  time 

78 

20 

63 

3 

2 

0 

differ  time 

83 

20 

64 

3 

2 

1 

same  time 

88 

21 

65 

3 

2 

1 

differ  time 

93 

22 

66 

0 

3 

1 

same  time 

96 

23 

67 

0 

3 

1 

differ  time 

99 

24 

68 

3 

0 

1 

same  time 

102 

25 

69 

3 

0 

1 

differ  time 

105 

26 

totals 

36 

27 

13 

63 

TCI 

1 

0 

2 

single 

106 

28 

TC2 

1 

0 

2 

single 

107 

30 

TC3 

1 

0 

2 

single 

108 

32 

TC4 

1 

0 

2 

single 

109 

34 

TC5 

1 

0 

2 

single 

110 

36 

TC6 

1 

0 

2 

single 

111 

38 

TC7 

1 

0 

2 

single 

112 

40 

totals 

7 

0 

14 

21 
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Appendix  L  -  Isolator 


L.l  Device  Description 

An  isolator  is  a  basic  device  used  in  fiber  optie  systems.  The  isolator  is  a  deviee  which  is 
used  to  pass  light  in  the  forward  direetion  while  highly  attenuating  light  moving  in  the  opposite 
direetion.  This  has  the  effeet  of  operating  as  a  “one-way  street”  and  prevents  reflected  light  from 
returning  to  a  light  source,  sueh  as  a  laser.  This  backward  propagation  of  reflected  light  ean  have 
negative  effects  on  the  source.  The  attenuation  is  a  fixed  amount,  usually  expressed  in  decibels 
(dBs). 

There  are  two  types  of  isolators,  the  polarization-dependent  and  the  polarization- 
independent.  The  dependent  version  of  the  isolator  is  usually  constructed  with  an  input  polarizer, 
a  Faraday  rotator  with  a  fixed  magnet  and  an  output  polarizer.  The  input  polarizer  filters  the 
incoming  light,  allowing  only  the  parallel  electric  field  components  of  an  incoming  beam  to  pass. 
The  Faraday  rotator  rotates  the  light  by  45°  then  outputs  it  to  the  second  linear  polarizer.  The 
output  light  is  aligned  45°  to  the  incoming  light.  In  the  reverse  direetion  the  incoming  light  is 
polarized  to  45°,  and  then  passes  through  the  Faraday  rotator  for  another  45°  rotation,  meaning 
the  light  is  now  polarized  perpendicular  to  the  input  polarizer  and  the  light  is  either  reflected  or 
absorbed  (Saleh  &  Teich,  1991).  See  Figure  1. 
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Figure  105.  A  polarization-dependent  isolator  (ThorLabs,  2013). 

The  independent  version  is  somewhat  more  complicated  as  the  light  is  split  into  to  two 
streams  by  a  birefringent  crystal,  then  passes  through  a  Faraday  rotator  which  rotates  the  light  by 
45°,  a  half-wave  plate  then  rotates  the  light  by  45°  again  and  finally  through  another  birefringent 
crystal  that  recombines  the  beams  into  the  output  port.  Reflected  light  passing  into  the  output 
port  passes  through  the  birefringent  crystal  and  split,  then  through  the  half-wave  plate  and 
Faraday  rotator.  When  the  light  encounters  the  second  birefringent  crystal,  the  light  is  channeled 
away  from  the  input  port  into  the  isolator  housing  (Saleh  &  Teich,  1991).  See  Figure  2.  Both 
types  of  isolator  may  be  used  in  a  QKD  device. 
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Figure  106.  Polarization- independent  isolator  (ThorLabs,  2013). 

The  Isolator  is  a  bidirectional  optical  component  with  one  optical  port.  Optical  signals 


arriving  at  the  input  port  are  propagated  to  the  other  port  after  a  defined  propagation  delay. 
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Signals  arriving  at  the  output  port  are  blocked  from  propagating  through  the  input  port.  The 
Isolator  is  sensitive  to  the  power  of  the  optical  signals  that  are  propagated  through  the 
component.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold,  the  Isolator  may  become 
permanently  damaged  which  changes  its  propagation  characteristics.  Similarly,  the  Isolator  is 
sensitive  to  the  temperature  in  the  environment  in  which  it  operates.  If  the  temperature  exceeds 
defined  thresholds,  the  Isolator  may  become  temporarily  degraded  or  permanently  damaged 
which  changes  its  propagation  characteristics.  If  temporarily  degraded,  the  device  may  recover 
to  normal  operating  behavior  after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  the  modeling  the  Isolator  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica  software 
program  that  modeled  the  Isolator.  The  SME  developed  a  series  of  use  cases  that  exercised  the 
functionality  of  the  device  over  a  wide  variety  of  conditions  and  verified  the  model  and  validated 
the  input  and  output  behavior  of  the  device  within  a  single  Mathematica  model  (worksheet).  The 
Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME  communicated  the 
behavior  of  the  Isolator  to  the  researcher.  Additional  information  came  from  product  data  sheets 
from  commercial  vendors  and  standard  texts  from  the  optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  Isolator 
using  the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated  to  the 
detailed  development  of  the  DEVS  model  of  the  Isolator.  Once  developed,  the  model  will  be 
simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  in  the  Mathematica 
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worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that  the  DEVS 
formal  model  matehes  the  behavior  of  the  Mathematiea  model  and  henee  the  real  eomponent. 

Onee  eompleted,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
ereated  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
eonstruetion  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 


Figure  107.  Symbol  for  the  Isolator  in  the  QKD  system  arehiteeture. 


L.2  Isolator  Conceptual  Model 
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Figure  108.  Isolator  eoneeptual  model. 


The  eoneeptual  model  for  an  Isolator  eonsists  of  two  optieal  input  ports  {Optini,  OptIn2}, 
two  optieal  output  ports  {OptOuti,  OptOut2},  and  one  environmental  input  port  {Evnin}.  The 
environmental  port  allows  external  sourees  to  eommunieate  ehanges  in  the  operational 
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environment  to  the  Isolator.  In  eomparison  to  the  Isolator  symbol  used  in  the  QKD  simulation 
architecture  shown  in  Figure  3,  a  single  bidirectional  optical  connection  is  decomposed  into  an 
optical  input  and  an  optical  output  in  the  conceptual  model.  This  is  necessary  to  properly 
represent  the  behavior  of  the  device  using  the  DEVS  formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  Isolator,  a  small  portion  of  the  signal 
will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  OptIni  in  Fig.  4  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  Isolator  calculates  the  power  of  the  incoming  packet  and  if  the  packet  comes  in  the 
normal  input  port,  it  is  sent  out  the  output  port  after  a  time  equaling  the  propagation  delay  of  the 
module  at  full  power  minus  some  small  amount  to  account  for  attenuation  through  the  device.  If 
an  incoming  packet  enters  through  the  device  output  port,  the  packet  is  output  through  the  input 
port  after  the  propagation  delay,  but  the  packet  power  is  heavily  attenuated.  Even  though  the 
isolator  is  meant  to  block  light  travelling  in  the  wrong  direction,  a  highly  attenuated  portion  of 
backward  propagating  light  will  still  pass  through  the  device. 

The  Isolator  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation.  External  environmental  messages 
sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the  Isolator  can 
determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In  either 
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case,  a  function  determines  how  the  propagation  ehanges  as  a  function  of  the  device  state  and 
current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interference  at  the  Single  Photon  Deteetor  (SPD)  devices  in  the  QKD  system  simulation. 
This  greatly  simplifies  the  modeling  of  all  of  the  other  optieal  eomponents  which  can  treat 
multiple  optieal  signals  as  independent  entities. 

L.3  Mathematical  Model 

For  a  detailed  mathematieal  deseription  of  the  Isolator,  refer  to  Seetion  10.8  whieh  contains 
the  Mathematiea  worksheet  provided  by  the  optieal  physies  SME. 

L.4  English-Language  Rules 

In  this  seetion,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
Isolator. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  whieh  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  eleared. 

•  OverTemp  is  a  flag  whieh  indicates  if  the  deviee  is  permanently  damaged  due  to  being 
exposed  to  temperatures  whieh  exeeed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Determine  the  input  port  number. 

•  Immediately  calculate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same 
port  number. 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Place  the  signal  into  a  queue  until  the  propagation  time  through  the  eomponent  has 
elapsed. 
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•  After  the  propagation  time  has  elapsed,  retrieve  the  input  optical  signal  from  the  queue, 
and  determine  the  input  port  of  the  signal. 

•  If  the  input  port  of  the  signal  matches  the  input  port  of  the  isolator,  slightly  attenuate  the 
output  signal  with  power  based  upon  the  input  optical  signal,  the  OverPower  flag,  the 
OverTemp  flag,  and  the  current  environment. 

•  If  the  input  port  of  the  signal  does  not  match  the  input  port  of  the  isolator,  heavily 
attenuate  the  output  optical  signal  based  upon  the  input  optical  signal,  the  OverPower 
flag,  the  OverTemp  flag,  and  the  current  environment. 

•  Send  the  attenuated  output  signal  out  of  the  optical  output  port  number  that  is  not  the 
same  as  the  input  port  number. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 


L.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  5  shows  the  phases  of  the  Isolator  in  the  boxes  and  the 
transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled  with  the  type  of 
transition  (dext  -  external  or  dint  -  internal)  and  the  significant  actions  that  take  place  during  the 
transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value  of  the  time 
advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase  and  an  entry 
showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs.  Note  there  is 
a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the  Isolator  at  the 
same  time. 
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state  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn> 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  109.  Isolator  phase  transition  diagram. 

L.6  Event-Trace  Diagram 

This  section  shows  various  examples  of  packets  entering  the  Isolator.  The  tables  list  the 
states  the  Isolator  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  Isolator,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes. 

Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 
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•  Queue:  contents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 

L.  6. 1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  44.  Case  I  state  list. 


Notes: 

entry/  store  over  over  interrupt  queue  assume 


time 

state 

1-packet 

exit 

no  env 

phase 

no  ext 

sigma 

0  Ctrl 

(X/) 

temp 

temp 

power 

respond 

(x/,  tp) 
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0 

sO 

entry 
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inf 

null 
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Figure  110.  Case  I  sequence  diagram. 


L.6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  45.  Case  II  state  list. 
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Notes: 

entry/  store  over  over  Interrupt  queue  assume 

time  state  exit  phase  sigma  (xi)  temp  temp  power  respond  (x/,  tp)  tp=5 

1-packet  0  env  1  opt  0  Ctrl 


0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

n 
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0 
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Figure  111.  Case  II  sequence  diagram. 
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L.6.3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 

Table  46.  Case  III  state  list. 

Notes: 

entry/  store  over  over  interrupt  queue  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 

1-packet  0  env  2  opt  0  Ctrl 


0 

sO 

entry 

passive 

inf 

null 
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sO 

exit 
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Figure  112.  Case  III  sequence  diagram. 

L.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 


Table  47.  Case  IV  state  list. 
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Figure  113.  Case  IV  sequence  diagram. 

L.  7  Isolator  Parallel  DEVS  Code 


Notes; 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 
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•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  Isolator  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  dgxt,  Sint,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  P  £  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp}  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  0  X  ^  5  is  the  external  state  transition  function; 

Sint  =  S  ^  S  '\s,  the  internal  state  transition  function; 

Scon  =  2  X  Xh  S  is  the  confluent  transition  function; 

/I  =  S'  — T*  is  the  output  function; 

to  =  S  ^  U  00  or  S  ^  .  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  to}^)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  Isolator  {Xm',  Ym^  S,  Sgxh  Sint^  Scow,  to) 
where 

tp  =  transmission  time  inside  the  attenuator 
temperature  ~  current  temperature  of  the  attenuator 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
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phase  =  {“passive”,  “reflect”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  current  optical  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optical  packet 
messagebag=  variable  that  stores  the  current  x  input  value(s)  {p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optical  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 
reflect  =  variable  that  stores  the  current  reflected  optical  packet 
reflect.port  =  variable  that  holds  the  current  reflection  output  port 
reflect.power  =  variable  that  holds  the  current  reflection  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
queue.current  =  variable  that  holds  the  currently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
e  =  elapsed  time  since  last  transition  occurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  scheduled  inputs 
queue_size()  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_reflected()  =  method  returns  the  first  unrefiected  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refiected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
insert  event  qO  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  f{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  fcurrenlv, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 
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calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  /[store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReflectedQ  =  method  that  calculates  reflection  power  of  an  optical  packet 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 
InPorts  =  {“Optini”,  “OptIn2”,  “Envin”}  with 

Xm  =  {(“Optini”,  Vopt),  (“OptIn2”,  Vopt),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 


OutPorts  =  {“OptOuti”,  “OptOut2”}  with 

Ym=  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  Yoptouti)}  is  the  set  of  output  ports  and  values. 

phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower  interruptRespond,  queue)  = 
{{“passive”,  “reflect”,  “respond”}  x  R/x  ExRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  V) 

External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower, interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  E  {“Optlnf’,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_first(^MeMe) 

reflect  =  (queue. current.p),  calcReflected(^MeMe. current. v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “respond”  and  p  E  {‘‘Optlnf’,  “OptIn2”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
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queue. current  =  queue_need_reflected() 
reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  —  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time,  delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

(phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x  \  ..xn) 
otherwise; 

Internal  Transition  Function: 

Sint(phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((pi,Vi),.... 

(Pn,Vn)))  = 


(“refleef’,  0,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn)) 
if  phase  =  “refleet”  and  need.reflect  !=  null 
need.reflect  =  queue_need_refleeted() 
current  =  need.reflect 

reflect  =  (current.p),  ealeRefleeted(cMrrent.v)) 
mark_refleeted(cMrrent) 

(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “refleet”  and  need.reflect  =  null 
need.reflect  =  queue_need_refleeted() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
time.delay  =  eurrent.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  ealeEorward(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
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outputPort  =  “OptOuti” 
if  InPort  =  “Optini” 

outputPulse  =  calcReverse(cMrren^.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
timeLeftRespond  =  propagation  delay 
else 

time. delay  =  timeLeftRespond 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  eurrent.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  oaloForward(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  oalcReverse(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower)  = 

(reflect. p,  reflect. v) 
if  phase  =  “refleet” 

(outputPort,  outputPulse) 
if  phase  =  “propagate” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

ta(phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  =  cr; 
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L.8  Mathematical  Model 


Pulse  propagation  considerations  for  the  Isolator  Module  within  the 
QKD  OMNet++  simulation  environment 

The  physics  arc  fairly  straight-forward  for  the  isloator.  There  are  typically  two  types;  polarualion  depeDdent  aitd 
polarization  independent.  Pokaiization  independent  simply  require  a  few  additional  components  (integral  to  the 
des'ice)  to  achiev  e  the  required  isolation  of  a  return  beam.  From  this  point  ITl  use  the  notation  of  jcl  for  polarization 
dependent  and  x2  for  polarization  independent  parameters. 

The  following  parameter  values  are  examples  of  typical  fiber-based  isolators  as  given  by  the  Gould  corporation. 

Note :  polarization  dependent  isolators  have  polaiization-maintaining  ffoer  inputs  and  outputs  (typically  Panda  fibcrl 
polarization  independent  isolators  typically  use  comity  SMF-28 

Pulse  Characteristics  (em.) 

These  parameters  arc  used  in  the  joncs  representation  of  the  standard  coherent  pulse  optical  message  packet. 

Pertinent  Pulse  Characteristict  for  the  Isolator  Module 

Kin  :■  Eo  (•  inpnt  olocecic  fiold  •) 

InputPolazization  :■  a  (•  input  polarization  •) 

The  effects  of  the  isolator  arc  primarily  upon  the  amplitude.  Eo.  How  ever,  as  is  typical,  the  parameters  arc  given  in  dB 
in  power  regime. 

laol  :■  45  (•  isolation,  tJbougliput  forward  warsus  throughput  ravarsa,  units  of  -dB  •) 
BandHidthl  :■  15  (•  bandwidth, 

*/-  from  tha  daclarad  wavalangth  (a.g.  1550nm)  units  of  nm  •) 

InsartLossl  :■  0.8  (•  inaartion  loss, 

loss  in  powar  duo  to  transmission  foward  through  davica,  units  of  -cB  •) 

KatinctAatiol  ;«  23  {•  aatinction  ratio, 

won't  currantly  ba  factorad  into  calculationa ,  units  of  dB  *) 

Ratliossl  :■  50  (•  rotum  loss,  signal  rofloctad  by  a  forward-fad  baaa,  units  of  -dB  •) 
Taa^Hl  :■  70  (•  swx  oparational  tanporatura,  units  of  ”C  •) 

TasgiLl  :■  -5  (•  au.n  oparational  tanparatum,  units  of  ‘C  •) 

Iso2  ;•  45  (*  isolation,  thoughput  forward  vorsus  throughput  raworsa,  units  of  dB  •) 
BancMidth2  :■  15  (•  bandwidth, 

•/-  from  tha  daclarad  wavalangth  (a.g.  1550nm)  units  of  nm  *) 

Insartloss2  :■  0.7  (•  inaartion  loss, 

loss  in  powar  dua  to  transmission  foward  through  davica,  units  of  -dB*) 

(•  aatinction  ratio  can't  ba  calculatad  w/o  dafinad  polarization  aaas*) 

ltatIosa2  :•  60  (*  raturn  loss,  signal  raflactad  by  a  forward-fad  baaa,  units  of  -dB*) 

TasgilU  :a  65  (*  swx  oparational  tamparatura,  units  of  "C  *) 

Tasg>I,2  :■  -10  (•  min  oparational  tasgiaratura,  units  of  •) 

Attenuation  Calculations  for  Isolators 

The  power  out  given  parameters  in  the  dB  regime,  is  calculated  as. 

Pout(Pin_,  dB_l  :•  Pin*!©*"'* 

However,  we  typically  deal  with  the  pulse  in  the  electric  field.  If  thaf  s  the  case,  the  proper  opciation  is. 

Eout[Kin_,  dB_]  :■  Kin*  V lO*'** 

Let's  use  the  polarization  independent  isolator  as  an  example,  with  a  forward  propagating  input  ampliutdc  of  Eo. 
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EautForward  •  Ein*'VlQ"^' 

0.922571  Ed 

The  ictlected  (rcfum  ki&s)  from  the  forward  propa$£alifi£  pulse  will  have  an  ampliutdc  of, 

Ex«t  .  Ein  »  V  io-«.tio..vlD  j, 

Q.OQlfo 

Ifwc  ^‘isumc  a  reverse  propagating  pulse  with  the  same  ampliliule,  the  Ihroughput  will  be, 

ftoutfirors*  •  Eo*  V  10'^“"''*  //  tJ 

a.OQ5e2J4II£D 

I  will  he  looking  at  a  few  isotalors  lo  observe  their  behavior  when  out  of  wavelength  range  |e.g.  1570  nm  £  A  £  1535 
nm).  A  good  paper  to  look  al  for  some  baste  tnfonnalian.  Including  some  icmpctBlure  and  wavelength  dependent 
behavior,  is^  K,W.  Chane  and  W.V.  Soria.  " Hinh-oertaramance  imvle-mode  f\ber  oolanzaiian-indeoetideni  isoia- 
OntLcs  Leii..  L5.  IWO. 

There  may  also  be  some  polarization  rotation  issues.  I'm  invesligation  that  right  now,  hut  the  things  above  should  bo 
good  fora  futii  approximation. 

Polarizaion  Calculations  -  Pertinent  to  only  polarization  independent  isolators 

Due  to  the  nalure/functkm  of  a  polaiizalion-indcpcfulent  rtbcr-ba.sed  isolator  the  beam  is  rotated  by  90".  Note  that  this 
rotation  ocours  in  a  "suigle-stage"  polarization  independent  isolator,  and  that  Larger  rotations  can  be  present  for  multi- 
slagc  polarization  independent  isolators.  .Although  it  can  be  easily  modiricd  lo  incorporate  multi-stage  isolatois.  we 
will  assume  a  single-stage  isolator  and  a  eloekwise  rotation,  such  that, 
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L.9  Appendix  C-  Component  Use  Case 

L.9.1  Respond  to  an  Optical  Packet  in  the  Isolator 

Optical  packet  arrives  at  the  isolator.  A  portion  of  optical  packet  reflects  back  down 
incoming  optical  line.  Place  the  optical  packet  into  the  optical  queue.  Check  to  see  if  optical 
packet  overpowers  the  isolator.  Records  overpower  condition,  if  applicable.  Remove  the  optical 
packet  from  the  queue  and  calculate  the  attenuated  optical  output  signal  based  on  the  input 
signal,  direction  of  input  and  the  current  component  state.  Propagate  the  attenuated  optical  output 
signal  out  of  the  component  optical  port  that  is  not  the  same  as  the  input  port. 


•  Identified  Alternative  Uses  Cases 

o  React  to  an  environmental  message 
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•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
o  Reflections  are  not  affected  by  component  state 
o  Incoming  electrical  signals  are  not  affected  by  component  state 


Initialization 

No  Optical  Output 


Normal  State 


•Reflections  are  not  configured  to  be  effected  by  state 
•Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  114.  Component  states. 


state  =  {phase,  o,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  115.  Isolator  phase  transition  diagram. 
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L.9.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  reflected  properly. 

•  Optieal  paeket  entered  and  removed  from  queue  in  proper  sequenee. 

•  Overpower  eondition  properly  reeognized  and  recorded. 

•  Optieal  paeket  attenuated  properly  to  the  limit  of  aeeuraey. 

•  Optieal  packet  propagated  out  the  eorreet  port  at  the  eorrect  time. 

L.9.3  Respond  to  an  Environmental  Packet  in  the  Isolator 

Environmental  paeket  arrives  at  the  eomponent.  Cheek  to  see  if  environmental  paeket 
temperature  sets  the  eomponent  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level 
returns  eomponent  from  degraded  state  to  normal  state.  Reeords  ehange  in  eondition,  if 
applicable.  Change  eomponent  funetion  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

L.  9.4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  paeket  received  properly 

•  Overtemperature  eondition  properly  reeognized  and  reeorded 

•  Change  of  state  eompleted  and  recorded  properly,  if  neeessary 

•  Change  eomponent  funetion  properly,  if  neeessary 

L.IO  Isolator  Test  Cases 

Eaeh  optieal  eomponent  was  tested  by  sending  inputs  into  the  eomponent,  eapturing  the 
output,  and  evaluating  the  output  line-by-line  to  eheek  behavior  and  timing.  Eaeh  eomponent  had 
eaeh  of  its  input  ports  (optieal,  environmental  (env),  and/or  eontrol  (etrl))  tested  singly,  then  in 
different  eombinations  of  ports  and  input  messages.  All  identified  errors  were  eorreeted  and  the 
eomponent  retested  until  it  funetioned  properly  for  eaeh  test  ease. 

To  test  an  optieal  port,  an  optical  message  is  injected  into  that  port  when  the  eomponent 
is  in  Passive  or  Respond  phase.  This  tests  eomponent  behavior  when  it  is  do  nothing  and 
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awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  processing. 
Control  messages  work  in  the  same  way,  but  force  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 

Table  5.  Isolator  Test  Cases 


Phase 

Case 

Inject  Ports 

Optl  Opt2 

Env 

Notes 

Running 

Totals 

opt#  env# 

Passive 

1 

1 

0 

0 

single 

1 

0 

2 

0 

1 

0 

single 

2 

0 

3 

0 

0 

1 

single 

2 

1 

4 

1 

1 

0 

same  time 

4 

1 

5 

1 

1 

0 

differ  time 

6 

1 

6 

1 

1 

1 

same  time 

8 

2 

7 

1 

1 

1 

differ  time 

10 

3 

8 

0 

1 

1 

same  time 

11 

4 

9 

0 

1 

1 

differ  time 

12 

5 

10 

1 

0 

1 

same  time 

13 

6 

11 

1 

0 

1 

differ  time 

14 

7 

20 

2 

0 

0 

same  time 

16 

7 

21 

0 

2 

0 

same  time 

18 

7 
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22 

2 

2 

0 

same  time 

22 

7 

23 

2 

2 

0 

differ  time 

26 

7 

24 

2 

2 

1 

same  time 

30 

8 

25 

2 

2 

1 

differ  time 

34 

9 

26 

0 

2 

1 

same  time 

36 

10 

n 

0 

2 

1 

differ  time 

38 

11 

28 

2 

0 

1 

same  time 

40 

12 

29 

2 

0 

1 

differ  time 

42 

13 

totals 

21 

21 

13 

42 

Respond 

41 

2 

0 

0 

single 

44 

13 

42 

0 

2 

0 

single 

46 

13 

43 

1 

0 

1 

single 

47 

14 

44 

2 

1 

0 

same  time 

50 

14 

45 

2 

1 

0 

differ  time 

53 

14 

46 

2 

1 

1 

same  time 

56 

15 

47 

2 

1 

1 

differ  time 

59 

16 

48 

0 

2 

1 

same  time 

61 

17 

49 

0 

2 

1 

differ  time 

63 

18 

50 

2 

0 

1 

same  time 

65 

19 

51 

2 

0 

1 

differ  time 

67 

20 

60 

3 

0 

0 

same  time 

70 

20 

61 

0 

3 

0 

same  time 

73 

20 

62 

3 

2 

0 

same  time 

78 

20 

63 

3 

2 

0 

differ  time 

83 

20 

64 

3 

2 

1 

same  time 

88 

21 

65 

3 

2 

1 

differ  time 

93 

22 

66 

0 

3 

1 

same  time 

96 

23 

67 

0 

3 

1 

differ  time 

99 

24 

68 

3 

0 

1 

same  time 

102 

25 

69 

3 

0 

1 

differ  time 

105 

26 

totals 

36 

27 

13 

63 

TCI 

1 

0 

2 

single 

106 

28 

TC2 

1 

0 

2 

single 

107 

30 

TC3 

1 

0 

2 

single 

108 

32 

TC4 

1 

0 

2 

single 

109 

34 

TC5 

1 

0 

2 

single 

110 

36 

TC6 

1 

0 

2 

single 

111 

38 

TC7 

1 

0 

2 

single 

112 

40 

totals 

7 

0 

14 

21 
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Appendix  M  -  Laser 


M.l  Device  Description: 

The  laser  is  an  optical  oscillator  that  contains  an  amplilication  medium  and  emits 
coherent  light  via  an  output  coupler.  Spontaneous  emission,  or  injected  seed  light,  is  amplified 
with  each  pass  through  the  amplification  portion  of  the  oscillator.  The  geometry  of  oscillator 
dictates  which  optical  wavelengths  and  modes  are  supported.  Lasers  come  in  many  forms  and  are 
generated  by  a  multitude  of  materials  used  as  the  active  medium.  Different  forms  include  solid- 
state  lasers,  gas  lasers,  dye  lasers,  x-ray  and  free-electron  lasers.  They  can  also  produce  pulsed  or 
continuous  beams  of  light  and  can  produce  specific  polarization  of  light  by  using  embedded 
polarizers  or  Brewster  windows. 

Active  materials  include  (solid-state):  ruby,  alexandrite,  sapphire,  yttrium  aluminum 
garnet,  gadolinium  gallium  garnet,  yttrium  lithium  fluoride,  transition-metal  and  lanthanide- 
metal  ions;  (gas):  helium-neon,  argon,  krypton,  carbon  dioxide,  xenon-chloride,  hydrogen 
fluoride;  (dyes):  polymethine  dyes,  xanthenes  dyes;  and  exotic  materials  used  in  the  high  energy 
x-ray  and  free-electron  lasers  (Saleh  &  Teich,  1991).  See  Figure  1  for  examples  of  lasers. 


Figure  116.  Example  of  lasers  (ThorLabs,  2013). 
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The  laser  is  a  unidireetional  optieal  eomponent  with  one  optieal  port  and  one  eleetrieal 
control  port  (unidirectional  in  the  sense  that  it  is  not  designed  to  pass  optical  signals  through  the 
device).  The  optical  port  is  the  output  port  for  the  coherent  optical  pulses  or  beam  created  inside 
the  device.  Optical  signals  arriving  at  the  optical  port  are  reflected  back  down  the  optical  path 
after  suffering  an  amount  of  attenuation.  The  laser  is  sensitive  to  the  power  of  the  optical  signals 
that  are  received  by  the  component.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold, 
the  laser  may  become  permanently  damaged  which  changes  its  attenuation  and  output 
characteristics.  Similarly,  the  laser  is  sensitive  to  the  temperature  in  the  environment  in  which  it 
operates,  as  temperature  changes  alter  the  physical  dimensions  of  the  device.  If  the  temperature 
exceeds  defined  thresholds,  the  laser  may  become  temporarily  degraded  or  permanently  damaged 
which  changes  the  output  wavelength.  If  temporarily  degraded,  the  device  may  recover  to  normal 
operating  behavior  after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  the  modeling  the  laser  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  series  of  use  cases  that  exercised  the  functionality  of  the  device  over  a 
wide  variety  of  conditions  and  verified  the  model  and  validated  the  input  and  output  behavior  of 
the  device.  Additional  information  came  from  product  data  sheets  from  commercial  vendors  and 
standard  texts  from  the  optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  laser  using 
the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated  to  the 
detailed  development  of  the  DEVS  model  of  the  laser.  Once  developed,  the  model  will  be 
simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  by  the  SME.  The  SME 
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will  then  review  the  MS4ME  simulation  output  to  verify  that  the  DEVS  formal  model  matches 
the  expected  behavior  and  hence  the  real  component. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 


Figure  117.  Symbol  for  the  laser  in  the  QKD  system  architecture. 

M.2  Laser  Conceptual  Model 


Envin 


Laser 


OptOut^ 


Optln^ 


Ctrl  In 


Figure  118.  Easer  conceptual  model. 


CtrlOut 


The  conceptual  model  for  a  laser  consists  of  one  optical  input  port  {Optini  },  one  optical 
output  port  {OptOuti},  one  environmental  input  port  {Evnin}  and  one  electrical  controller  input 
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port  and  one  electrical  controller  output  port  {Ctrlln,  CtrlOut}.  The  environmental  port  allows 
external  sources  to  communicate  changes  in  the  operational  environment  to  the  laser.  The 
electrical  controller  ports  allow  for  control  inputs  to  the  controller  and  responses  from  the  laser 
to  the  higher  system  functions. 

In  comparison  to  the  laser  symbol  used  in  the  QKD  simulation  architecture  shown  in 
Figure  2,  a  single  bidirectional  optical  connection  is  decomposed  into  an  optical  input  and  an 
optical  output  in  the  conceptual  model.  The  electrical  control  port  is  not  shown  for  clarity  in 
Figure  2,  and  is  also  decomposed  in  the  model  into  an  input  port  and  an  output  port.  This  is 
necessary  to  properly  represent  the  behavior  of  the  device  using  the  DEVS  formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  laser,  a  small  portion  of  the  signal  will 
be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model  decomposes 
each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  3  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  laser  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to  determine 
if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is  made  when 
the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once  overpowered  the 
device  will  permanently  change  attenuation  and  output.  External  environmental  messages  sent  to 
the  device  convey  the  temperature  of  the  operational  environmental  so  the  laser  can  determine  if 
it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In  either  case,  a 
function  determines  how  the  attenuation  and  output  changes  as  a  function  of  the  device  state  and 
current  temperature. 
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When  multiple  optieal  signals  arrive  at  a  port  at  the  same  time,  they  will  be  proeessed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation.  This 
greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 

The  laser  is  unique  among  the  optical  components  in  that  it  creates  optical  messages.  The 
laser  receives  a  command  from  the  controller  to  ‘fire’  a  pulse.  This  is  an  abstraction  how  a  laser 
actually  monitors  an  electrical  voltage  and  emits  a  pulse  when  the  voltage  exceeds  a  trigger 
voltage.  It  does  not  emit  a  pulse  until  the  voltage  drops  below  the  trigger  voltage  and  then 
exceeds  the  trigger  voltage. 

Upon  receipt  of  a  ‘fire’  or  ‘laser  on’  message,  the  laser  creates  an  optical  pulse  message 
with  predefined  characteristics  and  sends  it  out  the  optical  port.  The  time  between  receipt  of  the 
message  and  emission  of  the  pulse  has  a  random  factor  supplied  by  a  random  Gaussian  draw.  In 
the  case  of  the  demonstration  architecture,  the  optical  pulse  is  modeled  on  the  output  of  the  ID 
Quantique  IDS 00  laser  (ID  Quantique  SA,  2011). 

M.3  Mathematical  Model 

There  is  no  detailed  mathematical  description  of  the  laser  in  Section  1 1.8. 

M.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the  laser. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 
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When  an  optical  signal  arrives: 

•  Determine  the  input  port  number. 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Calculate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same  port  number. 
When  an  environmental  message  arrives: 

•  Update  the  CurrrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

When  a  control  message  arrives: 

•  Determine  if  it  is  an  “on”  or  “off’  message. 

•  Output  optical  packets  if  the  message  is  an  “on”  or  stop  packet  output  if  it  is  an  “off’ 
message 

•  Respond  to  the  controller  with  an  acknowledgement  message. 

M.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  laser  in  the  boxes  and  the 
transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled  with  the  type  of 
transition  (dext  -  external  or  dmt  -  internal)  and  the  significant  actions  that  take  place  during  the 
transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value  of  the  time 
advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase  and  an  entry 
showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs.  Note  there  is 
a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the  laser  at  the 
same  time. 
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state  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  laserpower,  queue. xl..xn} 


dint/laserpower=OPF 


^  dext  OPT/  check  overpower;  insert 


tastime 

delay 


dext  ENV/ 
check 
overtemp; 
\J/update  temp 


Passive 

A=0 


Xdext  ENV/ 

'  check 
overtemp; 
update  temp 


dext 

CTRL/ 

update 

laser 

power 


dext  CTRL/  set  time  left 


dint/  interruptRespond=''N‘* 


dint/ 
laser 
power 
=  ••off" 


•dint/ 
insert  (xi, 
ta) 


^  Update 
Laser 

A=ctrl  msg  - 

V - , — - dint/  needRespond  sY 


r  Reflect  1 

iA=reflectlon)^ 

- 1 — IK — 


dint/  laserpower=ON;  set  ta 


I  Create  Pulse 
|A=output  pulse 


|ta=time 

delay 


dext  OPT/  update  queue  ta;  insert  (xi,ta)  ta  =0 


dint/  interruptRespond^Y;  set  ta  ta=time  delay 

*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 


Figure  119.  Laser  phase  transition  diagram. 

M.6  Event-Trace  Diagram 

This  section  shows  various  examples  of  packets  entering  the  laser.  The  tables  list  the 
states  the  laser  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state  number, 
with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state  variable, 
current  temperature  of  the  laser,  the  over  temperature  flag  variable  and  the  over  power  flag 
variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents  of  the  store 
state  variable  and  any  notes. 

Explanations  for  each  column: 


•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Interrupt  Respond:  shows  the  value  of  the  interrupt  respond  variable 

•  Need  Respond:  shows  the  value  of  the  need  respond  variable 

•  Easer  Power:  shows  the  value  of  the  laser  power  variable 

•  Queue:  contents  of  the  queue  for  that  state 
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•  Notes;  any  notes  for  that  state 

M.  6. 1  CASE  I:  Initial  Passive  with  Single  Control  Packet  Arriving  at  Time  0 

Table  48.  Case  I  state  list. 


time 

state 

entry/ 

exit 

phase 

sigma 

store 

(xi) 

temp 

over 

temp 

over 

power 

interrupt 

respond 

need 

respond 

laser 

power 

queue 

(X/, 

tp) 

Notes: 

1  Ctrl 

0  env 

0  opt 

0  Ctrl 

0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

n 

n 

off 

null 

0 

sO 

exit 

passive 

0 

Ctrl 

c 

n 

n 

n 

n 

off 

null 

0 

si 

entry 

update 

laser 

0 

Ctrl 

c 

n 

n 

n 

n 

off 

null 

0 

si 

exit 

update 

laser 

2xl0''8 

Ctrl 

c 

n 

n 

n 

n 

on 

null 

0 

s2 

entry 

create 

pulse 

2xl0''8 

Ctrl 

c 

n 

n 

n 

n 

on 

null 

2x10'' 

8 

s2 

exit 

create 

pulse 

0 

Ctrl 

c 

n 

n 

n 

n 

off 

null 

2x10'' 

8 

s3 

entry 

passive 

inf 

Ctrl 

c 

n 

n 

n 

n 

off 

null 

1  packet,  0  environmental  events,  0  optical  events,  0  control  events 


Passive 

Update 

Laser 

Create 

Pulse 

Reflect 

1 

1 

1 

1 

dext  control  message 


—  dint  control  message 


I 

dint  control  I  message 


I 


dint  opt 
message 


Figure  120.  Case  I  sequence  diagram. 

M.6.2  CASE  II:  Initial  Passive  with  Single  Control  Packet  Arriving  at  Time  0  and  I  Optical 
Packet  Arriving  Time  1x10^8 


Table  49.  Case  II  state  list. 
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Figure  121.  Case  II  sequence  diagram. 

M.6.3  CASE  III:  Initial  Passive  with  Single  Control  Packet  Arriving  at  Time  0  and  I 
Environmental  Packet  Arriving  at  Time  IxIO'^S 

Table  50.  Case  III  state  list. 
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Figure  122.  Case  III  sequence  diagram. 

M.6.4  CASE  IV:  Initial  Passive  with  Single  Control  Packet  Arriving  at  Time  0  and  I  Control 
Packet  Arriving  at  Time  1x10^8 


Table  5 1 .  Case  IV  state  list. 
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Figure  123.  Case  IV  sequence  diagram. 

M.  7  Laser  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 
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•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  “needRespond”,“laserpower”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“laserpower”  =  flag  variable  set  when  device  is  turned  on 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  laser  we  define: 

Parallel-DEVS  atomic  M=  {Xm,  Ym,  S,  Sgxt,  Sint,  Scon,  to) 

Where: 

Xm  =  {{p,v)  I  p  G  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp)  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  0  X  S'  is  the  external  state  transition  function; 

Sint  =  S  ^  S  is  the  internal  state  transition  function; 

Scon  =  2  X  ^  S  is  the  confluent  transition  function; 

=  S  — >  T*  is  the  output  function; 
ta  =  S^Plvt^oxS^R,  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  laser  (Xm?  Tm?  S,  Sexti  Slntt  Scotf,  tO) 
where 

tp  =  transmission  time  inside  the  attenuator 
temperature  =  current  temperature  of  the  attenuator 
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phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “reflect”,  “respond”,  “update  deteetor”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  optieal  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
needRespond=  flag  variable  set  when  both  Refleet  and  UpdateDetector  respond  to  inputs 
laserpower  =  flag  variable  set  when  device  is  turned  on 

attenpower  =  variable  the  holds  the  attenuated  power  of  the  eurrent  optical  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optieal  paeket 
messagebag=  variable  that  stores  the  current  x  input  value(s)  {p,v) 

damaged.power  =  variable  that  holds  the  eomponent  damaged  optical  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  refleeting 
reflect  =  variable  that  stores  the  current  refleeted  optical  packet 
reflect.port  =  variable  that  holds  the  eurrent  reflection  output  port 
reflect.power  =  variable  that  holds  the  eurrent  reflection  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
ctrlOutput  =  variable  that  stores  the  output  control  message  response 
size=  variable  that  holds  the  number  of  events  in  the  queue 
queue.current  =  variable  that  holds  the  eurrently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timeLeftRespond  =  time  left  in  Respond  phase  for  the  eurrent  optical  packet 
autoPulseInterval=  automatie  pulse  interval  in  seconds 
e  =  elapsed  time  since  last  transition  oeeurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  eontainer  object  to  store  the  seheduled  inputs 
queue_size()  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_reflected()  =  method  returns  the  first  unrefiected  queue  event 
queue_elear()  =  method  that  elears  the  queue  of  all  entries 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refieeted()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
etrlMsgO  =  method  that  generates  a  response  message  to  received  control  messages 
outputMsgO  =  method  that  generates  the  response  message  to  reeeived  optical  packets 
insert_event_q()  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
ealePeakO  =  function  that  calculates  full  width,  half  maximum  power  ealculation  of  the  optical 
pulse 
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calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  fistore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  /{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  j{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  J{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  j{current.v,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReflectedO  =  method  that  calculates  reflection  power  of  an  optical  packet 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 

q.Vmm  =  minimum  value  in  the  queue 

v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 
InPorts  =  {“Optini”,  “Envin”,  “Ctrlln”}  with 

Xm  =  {(“Optini”,  Vopt),  (“Envin”,  Venv),  (“Ctrlln”,  Vctri)}  is  the  set  of  input  ports  and  values. 
OutPorts  =  {“OptOuti”,  “CtrlOut”}  with 

Ym=  {(“OptOuti”,  Yoptouti),  (“CtrlOut”,  Yctriout)}  is  the  set  of  output  ports  and  values. 
phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower  interruptRespond,  needRespond, 
laserpower,  queue)  =  {{“passive”,  “reflect”,  “create  pulse”,  “update  laser”}  x  R^x  V  x  R  x 
{“Y”,  “N”}  X  {“Y”,”N”}  X  {“Y”,”N”}  x{“Y”,”N”}  x  {“on”,  “off’}  x  V) 

External  Transition  Function: 

dextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  laserpower 

,needRespond,  queue,  e,  ((p„v;),....  (p„,v„)))  = 

(“update  laser”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

laser  power, queue. x\..xn) 

if  phase  =  “passive”  and  p  =  “Ctrlln” 
if  messagebag.status=  “statuscheck  “ 
laserpower  =  “off’ 
if  messagebag.status  =  “laserfire” 
laserpower  =  “on” 
ctrlOutput  =  ctrlMsg(5tore) 
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(“reflect”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

laserpower,  queue. x\..xn) 

if  phase  =  “passive”  and  p  —  “Optini” 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_lirst(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflect”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

laserpower,  queue.x\..xn) 

if  phase  =  “create  pulse”  and  p  =  “Optini” 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_need_reflected() 
reflect  =  (queue. current.p),  cadcRedQCiQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
timcLeftRespond  =  timeLeftRespond  -  e 

(“update  laser”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

laserpower,  queue. x\..xn) 

if  phase  =  “create  pulse”  and  p  —  “Ctrlln” 
if  messagebag.status=  “statuscheck  “ 
ctrlOutput  =  ctrlMsg(5tore) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 
if  messagebag.status  =  “laserfire” 
interruptRespond^  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“create  pulse”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  laserpower,  queue. x\..xn) 

if  phase  =  “create  pulse”  and  p  =  “Envin” 
timeLeftRespond  =  time_delay-  e 
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temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

laserpower,  queue.x\..xn) 

if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

{phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  laserpower) 
otherwise; 

Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  interrupRespond,  needRespond, 

laserpower)  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

laserpower,  queue.x\..xn) 

if  phase  =  “refleet”  and  need.reflect  !=  null 
need.reflect  =  queue_need_refleeted() 
current  =  need.reflect 

reflect  =  (current. p),  caleRefleeted(cMrrent.v)) 
mark_refleeted(cMrrent) 

(“ereate  pulse”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  laserpower,  queue. x\..xn) 
if  phase  =  “refleet”  and  interruptRespond  =  “Y”  and  needreflect  =  0 
need.reflect  =  queue_need_refleeted() 
if  interruptRespond  =  “Y” 
time_delay  =  timeLeftRespond 
queue_elear() 

(“update  laser”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

laserpower,  queue.x\..xn) 

if  phase  =  “refleet”  and  needRespond  =  “Y” 
if  messagebag.status=  “statuseheek  “ 
laserpower  =  “off’ 
ctrlOutput  =  ctrlMsg(5tore) 
if  messagebag.status  =  “laserfire” 
laserpower  =  “on” 
queue_clear() 


419 


(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

laserpower,  queue.x\..xn) 

if  phase  =  “reflect”  and  interruptRespond  =  “N” 
queue_clear() 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

laserpower,  queue.x\..xn) 

if  phase  =  “create  pulse” 
needRespond  =  “N” 
interruptRespond=  “N” 
laserpower  =  “OFF” 


(“create  pulse”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  laserpower,  queue.x\..xn) 
if  phase  =  “update  laser”  and  {laserpower  =  “on”  or  interruptRespond=  “Y”) 
if  interruptRespond  =  “Y” 
time. delay  =  timeLeftRespond 
else 

time,  delay  =  autoPulseInterval 


(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  overpower,  interruptRespond, 

needRespond,  laserpower,  queue. x\..xn) 


if  phase  =  “update  laser”  and  laserpower  =  “off’ 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

laserpower,  queue)  = 

{reflect. p,  reflect. v) 
if  phase  =  “reflecf  ’ 

(Outputi,  outputPulse) 
if  phase  =  “create  pulse” 

("CtrlOut",  ctrlOutpuf) 
if  phase  =  "update  laser" 

0  (null  output) 
otherwise; 
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Time  advance  Function: 


taiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

laserpower,  queue)  =  cr; 


M.8  Mathematical  Model 


id300  SERIES 


SPECIFICATIONS  (T»25'*C) 


Parameter 

Min 

Typical 

Max 

Units 

Wavelength 

1290 

1310 

1330 

nm 

Wavelength 

1520 

1550 

1580 

nm 

Spectra  width  (FWHM)  -  FP  laser  type 

7 

15 

nm 

Spectral  width  (FWHMj  -  DFB  laser  h/pe 

0.6 

1.5 

nm 

Frequency  range 

0 

500 

MHz 

Pulse  duration 

0.3* 

0.5 

ns 

Peak  power 

0-7 

1 

mW 

Output  power  at  1  MHz 

-36 

-35 

-34 

dBm 

Trigger  inpuT*  NIM.  ECL.  PECL  LVPECL.  TTL.  TTL  500 

*  can  be  increased  up  to  2ns  upon  request 

**  choose  one  trigger  input  from  tNs  list.  See  ordering  information  below. 

GENERAL  INFORMATION 

Operating  Temperature 
Dimensions  LxWxH 
Weight 

Optical  Connector 
Electronic  Connector 
Fiber  Type 
Power  Supply 

WARNING 

CLASS  1  LASER  PRODUCT 

CLASSIFIED  PER  lEC  60825-1.  Ed  1.2.  2001-08 

Component  Use  Case 


+10*C  to*30*C 

185  mm  x  172  mm  x  55  mm 

915g 

FC-PC 

BNC 

SMF 

100  -  240  VAC  (autoseiect) 


OPERATING  PRINCIPLE 

“I  I - - 1  T - * - 1 


(ID  Quantique  SA,  2011) 

M.9 


M.9.1  Respond  to  an  Optical  Packet  in  the  Laser 
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Optical  packet  arrives  at  laser.  A  portion  of  optical  packet  reflects  back  down  incoming  optical 
line.  Check  to  see  if  optical  packet  overpowers  the  EVOA.  Records  overpower  condition,  if 
applicable. 

•  Identified  Alternative  Uses  Cases 

o  Respond  to  a  control  message 
o  React  to  an  environmental  message 

•  Assumptions 

o  Component  has  eompleted  initialization  sequence  at  least  once 
o  Reflections  are  not  affected  by  component  state 
o  Incoming  electrical  signals  are  not  affected  by  component  state 


Under  d 
tempera 
power  tl 


'Reflections  are  not  configured  to  be  effected  by  state 
'Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  124.  Component  states. 


422 


state  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  laserpower,  queue. xl..xn} 


dint/laserpower=OPF 


^  dext  OPT/  check  overpower;  insert 


Passive 

A=0 


Xdext  ENV/ 

'  check 
overtemp; 
update  temp 


dext 

CTRL/ 

update 

laser 

power 


tastime 

delay 


dext  CTRL/  set  time  left 


dext  ENV/ 
check 
overtemp; 
\J/update  temp 


dint/  interruptRespond=''N‘* 


dint/ 
laser 
power 
=  ••off" 


*dlnt/ 
insert  (xi, 
ta) 


^  Update 
Laser 

A=ctrl  msg  - 

V - , — - dint/  needRespond  sY 


I  Reflect  I 
iA=reflectlon)^ 

- 1 — IK — 


dint/  laserpower=ON;  set  ta 


I  Create  Pulse 
|A=output  pulse 


|ta=time 

delay 


dext  OPT/  update  queue  ta;  insert  (xi,ta)  ta  =0 


dint/  interruptRespond^Y;  set  ta  ta=time  delay 

*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 


Figure  125.  Laser  phase  transition  diagram. 

M.9.2  Respond  to  Optical  Packet  End  Goals 


•  Optical  packet  reflected  properly 

•  Overpower  condition  properly  recognized  and  recorded 


M.9.3  Respond  to  an  Environmental  Packet  in  the  Laser 

Environmental  packet  arrives  at  the  component.  Check  to  see  if  environmental  packet 
temperature  sets  the  component  to  degraded  or  damaged  state.  Check  to  see  if  temperature  level 
returns  component  from  degraded  state  to  normal  state.  Records  change  in  condition,  if 
applicable.  Change  component  function  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

M.9.4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 

•  Overtemperature  condition  properly  recognized  and  recorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

M.9.5  Respond  to  a  Control  Message  in  the  Laser 
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Control  Message  arrives  at  the  eomponent.  Component  deeodes  message  properly.  Reeords 
change  in  condition  or  state,  if  applicable.  Change  component  function  if  in  degraded  or 
damaged  state  or  by  change  in  component  condition,  if  necessary. 

•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
M.9. 6  Respond  to  Control  Message  End  Goals 

•  Control  message  received  properly 

•  Change  of  condition  or  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

M.IO  Laser  Test  Cases 

Each  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  check  behavior  and  timing.  Each  component  had 
each  of  its  input  ports  (optical,  environmental  (env),  and/or  control  (ctrl))  tested  singly,  then  in 
different  combinations  of  ports  and  input  messages.  All  identified  errors  were  corrected  and  the 
component  retested  until  it  functioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  processing. 
Control  messages  work  in  the  same  way,  but  force  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
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phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 

Table  5.  Laser  Test  Cases 


Inject  Ports 

Running  Totals 

Phase 

Case 

Optl 

Ctrl 

Env 

Notes 

opt  # 

env  # 

Ctrl  # 

Passive 

1 

1 

0 

0 

single 

1 

0 

0 

2 

0 

1 

0 

single 

1 

0 

1 

3 

0 

0 

1 

single 

1 

1 

1 

4 

1 

1 

0 

same  time 

2 

1 

2 

5 

1 

1 

0 

differ  time 

3 

1 

3 

6 

1 

1 

1 

same  time 

4 

2 

4 

7 

1 

1 

1 

differ  time 

5 

3 

5 

8 

0 

1 

1 

same  time 

5 

4 

6 

9 

0 

1 

1 

differ  time 

5 

5 

7 

10 

1 

0 

1 

same  time 

6 

6 

7 

11 

1 

0 

1 

differ  time 

7 

7 

7 

20 

2 

0 

0 

same  time 

9 

7 

7 

21 

0 

1 

0 

same  time 

9 

7 

8 

22 

2 

1 

0 

same  time 

11 

7 

9 

23 

2 

1 

0 

differ  time 

13 

7 

10 

24 

2 

1 

1 

same  time 

15 

8 

11 

25 

2 

1 

1 

differ  time 

17 

9 

12 

26 

0 

1 

1 

same  time 

17 

10 

13 

27 

0 

1 

1 

differ  time 

17 

11 

14 

28 

2 

0 

1 

same  time 

19 

12 

14 

29 

2 

0 

1 

differ  time 

21 

13 

14 

totals 

21 

14 

13 

35 

Respond 

41 

2 

0 

0 

single 

23 

13 

14 

42 

1 

1 

0 

single 

24 

13 

15 

43 

1 

0 

1 

single 

25 

14 

15 

44 

2 

1 

0 

same  time 

27 

14 

16 

45 

2 

1 

0 

differ  time 

29 

14 

17 
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46 

2 

1 

1 

same  time 

31 

15 

18 

47 

2 

1 

1 

differ  time 

33 

16 

19 

48 

1 

1 

1 

same  time 

34 

17 

20 

49 

1 

2 

1 

differ  time 

35 

18 

22 

50 

2 

0 

1 

same  time 

37 

19 

22 

51 

2 

0 

1 

differ  time 

39 

20 

22 

60 

3 

0 

0 

same  time 

42 

20 

22 

61 

1 

1 

0 

same  time 

43 

20 

23 

62 

3 

1 

0 

same  time 

46 

20 

24 

63 

3 

1 

0 

differ  time 

49 

20 

25 

64 

3 

1 

1 

same  time 

52 

21 

26 

65 

3 

1 

1 

differ  time 

55 

22 

27 

66 

1 

1 

1 

same  time 

56 

23 

28 

67 

1 

1 

1 

differ  time 

57 

24 

29 

68 

3 

0 

1 

same  time 

60 

25 

29 

69 

3 

0 

1 

differ  time 

63 

26 

29 

totals 

42 

15 

13 

57 

TCI 

1 

1 

2 

single 

64 

28 

30 

TC2 

1 

1 

2 

single 

65 

30 

31 

TC3 

1 

1 

2 

single 

66 

32 

32 

TC4 

1 

1 

2 

single 

67 

34 

33 

TC5 

1 

1 

2 

single 

68 

36 

34 

TC6 

1 

1 

2 

single 

69 

38 

35 

TC7 

1 

0 

2 

single 

70 

40 

35 

totals 

7 

6 

14 

13 

Notes:  23  -  INIT  control  message  sent;  OPTl  &  Ctrl  -  differ  time  -  Passive 


24  -  INIT  control  message  sent  -  OPTl  &  Ctrl  -  same  time  -  Passive 
63  -  INIT  control  message  sent  -  OPTl  &  Ctrl  -  same  time  - 
Respond 

66  -  INIT  control  message  sent  -  Ctrl  &  ENV  -  same  time  -  Respond 
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Appendix  N  -  Panda  Polarization  Maintaining  Optical  Fiber  (PM 


Fiber) 


N.l  Device  Description: 


PM  fiber  is  used  in  optieal  eomponents  where  it  is  required  that  optieal  polarization  is 
maintained.  Like  single-mode  fiber,  it  is  a  cylindrical  optical  waveguide  made  from  a  low-loss 
material,  such  as  silica  glass.  Light  that  is  properly  introduced  into  the  fiber  maintains  its  linear 
polarization  during  propagation.  In  the  case  of  Corning  fiber,  using  two  stressors  within  in  the 
fiber  creates  high  birefringence  resulting  in  the  fiber  maintaining  the  polarization  (Coming, 
2013).  See  Figure  1  for  a  typical  cross-sectional  view  of  a  PANDA  fiber. 


■  Core 
Cladding 

Stress  Applying  Part 
Inner  Coating 
Outer  Coating 

Figure  126.  Cross-section  of  a  PANDA  PM  fiber  (Coming,  2013). 


PM  fiber  is  a  specialty  fiber  that  intentionally  uses  the  strong  birefringence  in  two  modes. 
Light  travels  down  one  of  the  modes  faster  than  down  the  other  (fast  and  slow  axes).  If  the  input 
light  is  polarized  and  oriented  along  either  mode,  it  maintains  its  polarization  state  even  if  the 
fiber  is  stressed  (OZOptics,  2014).  Typically,  PM  fiber  is  used  in  components  that  cannot  have 
drift  in  the  polarization  state  (such  as  fiber  interferometers  and  some  fiber  lasers)  (RPPhotonics, 
2013) . 


427 


The  PM  fiber  is  a  bidireetional  optieal  eomponent  with  two  optieal  ports.  Light  entering 
the  primary  port  is  propagated  through  the  fiber,  suffering  both  a  slight  attenuation  from  the 
material  of  the  deviee  and  a  small  propagation  delay  dependent  on  the  temperature  of  the  fiber. 
The  material  is  sensitive  to  the  power  of  the  optieal  signals  that  are  propagated  through  the 
eomponent.  If  the  optieal  power  of  a  pulse  exeeeds  a  defined  threshold,  the  PM  fiber  may 
beeome  permanently  damaged  whieh  changes  its  propagation  characteristics.  Similarly,  it  is 
sensitive  to  the  temperature  in  the  environment  in  which  it  operates.  If  the  temperature  exceeds 
defined  thresholds,  the  PM  fiber  may  become  temporarily  degraded  or  permanently  damaged 
which  changes  its  propagation  characteristics.  If  temporarily  degraded,  the  device  may  recover  to 
normal  operating  behavior  after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  the  modeling  the  PM  fiber  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica  software 
program  that  modeled  the  PM  fiber.  The  SME  developed  a  series  of  use  cases  that  exercised  the 
functionality  of  the  device  over  a  wide  variety  of  conditions  and  verified  the  model  and  validated 
the  input  and  output  behavior  of  the  device  within  a  single  Mathematica  model  (worksheet).  The 
Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME  communicated  the 
behavior  of  the  PM  fiber  to  the  researcher. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  PM  fiber 
using  the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated  to  the 
detailed  development  of  the  DEVS  model  of  the  PM  fiber.  Once  developed,  the  model  will  be 
simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  in  the  Mathematica 
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worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that  the  DEVS 
formal  model  matehes  the  behavior  of  the  Mathematiea  model  and  henee  the  real  eomponent. 

Onee  eompleted,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
ereated  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
eonstruetion  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 

(p^ 

Figure  127.  Symbol  for  Polarization  Maintaining  Eiber  in  the  QKD  system  arehiteeture. 

N.2  Polarization  Maintaining  Fiber  Conceptual  Model 

Envin 


OptOut2 


Optln2 


Figure  128.  PM  fiber  eoneeptual  model. 


Optlrii 

w 

OptOuti 

PM  Fiber 

The  eoneeptual  model  for  a  PM  fiber  eonsists  of  two  optieal  input  ports  {Optini,  OptIn2}, 
two  optieal  output  ports  {OptOuti,  OptOut2},  and  one  environmental  input  port  {Evnin}.  The 
environmental  port  allows  external  sourees  to  eommunieate  ehanges  in  the  operational 
environment  to  the  PM  fiber.  In  eomparison  to  the  PM  fiber  symbol  used  in  the  QKD  simulation 


429 


architecture  shown  in  Fig.  1,  a  single  bidirectional  optical  connection  is  decomposed  into  an 
optical  input  and  an  optical  output  in  the  conceptual  model.  This  is  necessary  to  properly 
represent  the  behavior  of  the  device  using  the  DEVS  formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  PM  fiber,  a  small  portion  of  the  signal 
will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  2  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  PM  fiber  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation.  External  environmental  messages 
sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the  PM  fiber  can 
determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In  either 
case,  a  function  determines  how  the  attenuation  changes  as  a  function  of  the  device  state  and 
current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation. 
This  greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat 
multiple  optical  signals  as  independent  entities. 

It  is  important  to  note  that  the  PM  fiber  only  preserves  polarization  of  light  that  is 
injected  along  the  two  axes  and  misalignment  between  connectors  causes  unusual  effects  on  the 
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light.  The  current  conceptual  model  does  not  take  these  effects  into  account  and  presumes  that  all 
light  injected  into  the  fiber  is  aligned  properly  with  the  slow  and  fast  axis. 

N.3  Mathematical  Model 

For  a  detailed  mathematical  description  of  the  PM  fiber,  refer  to  Section  12.8  which  contains 
the  Mathematica  worksheet  provided  by  the  optical  physics  SME. 

N.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the  PM 
fiber. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  is  less  than  the  minimum 
power,  drop  the  pulse.  If  the  optical  power  exceeds  a  defined  damage  threshold,  set  the 
OverPower  flag. 

•  Place  the  optical  packet  into  the  queue. 

•  Remove  the  packet  from  the  queue;  calculate  the  attenuated  output  optical  signal  based 
upon  the  input  optical  signal,  the  OverPower  flag,  the  OverTemp  flag,  and  the  current 
environment  and  calculate  the  delay  through  the  fiber  based  on  its  length. 

•  Send  the  attenuated  and  delayed  output  signal  out  of  the  optical  output  port  number  that 
is  not  the  same  as  the  input  port  number. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 
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•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

N.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  PM  fiber  in  the  boxes  and 
the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled  with  the  type 
of  transition  (dext  -  external  or  dint  -  internal)  and  the  significant  actions  that  take  place  during  the 
transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value  of  the  time 
advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase  and  an  entry 
showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs.  Note  there  is 
a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the  PM  fiber  at 
the  same  time. 


state  =  {phase,  o,  store,  temperature,  overtemp,  overpower, 
interruptRespond,  queue. xl..xn} 


dext  OPT/ 
OPTpwr  < 
minpwr 


ta  = 


dint/ 

queue 

=0 


ta  = 
00 


dext  OPT/ 
update 
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insert 
(xi,ta) 
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time 

delay 
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dext  ENV/ 
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Figure  129.  PM  fiber  phase  transition  diagram. 
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N.  6  Event-Trace  Diagram 


This  section  shows  various  examples  of  packets  entering  the  PM  fiber.  The  tables  list  the 
states  the  PM  fiber  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  PM  fiber,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes. 


Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Queue:  contents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 

N.  6. 1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  52.  Case  I  state  list. 


entry/ 

store 

over 

over  interrupt 

queue 

Notes: 

assume 

time  state 

1-packet 

exit 

no  env 

phase 

no  ext 

sigma 

0  Ctrl 

(X/) 

temp  temp 

power  respond 

(x/,  tp) 

tp=5 
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sO 
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inf 

null 

c 

n 

n 

n 
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sO 
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5 

xl 
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n 

n 

n 

null 

0 

si 

entry 

respond 

5 

xl 
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n 

n 

n 

null 
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si 
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respond 
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xl 
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null 
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S2 
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n 

n 
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1  packet,  0  environmental  events,  0  external  events 


Figure  130.  Case  I  sequence  diagram. 

N.  6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  53.  Case  II  state  list. 

Notes: 

entry/  store  over  over  interrupt  queue  assume 


state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 

1-packet  0  env  1  opt  0  Ctrl 


0 

sO 

entry 
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n 

n 
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0 

sO 
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1  packet,  0  environmental  events,  1  external  event  (with  1  packet)  at  e=2 


Figure  131.  Case  II  sequence  diagram. 

N.6,3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 

Table  54.  Case  III  state  list. 

Notes: 

entry/  store  over  over  interrupt  queue  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 


1-packet  0  env  2  opt  0  Ctrl 


0 

sO 
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Figure  132.  Case  III  sequence  diagram. 
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N.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 

Table  55.  Case  IV state  list. 

Notes: 

entry/  store  over  over  interrupt  queue  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 

1-packet  1  env  0  ext  0  Ctrl 
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Figure  133.  Case  IV  sequence  diagram. 
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N.  7  Single  Mod  Fiber  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  fixed  PM  fiber  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  8ext,  8int,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp}  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  2  X  ^  5*  is  the  external  state  transition  function; 

Sint  =  S  S  is  the  internal  state  transition  function; 

Scon  =  0 X  X^p  Sis  the  confluent  transition  function; 

^  T*  is  the  output  function; 

ta  =  S  Rn  U  CO  or  S  is  the  time  advance  function; 
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Q  :=  {(s,e)  \  s  E  S,  0<  e  <  ta(s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomie  instanee  of  P-DEVS. 

DEVS  PM  fiber  S^  ^exh  ^inh  to) 

where 

tp  =  transmission  time  inside  the  attenuator 
temperature  =  eurrent  temperature  of  the  attenuator 

phase  ~  eontrol  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  current  optical  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optical  packet 
messagebag=  variable  that  stores  the  current  x  input  value(s)  {p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optical  power  level  parameter 

damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 

current  =  variable  that  stores  the  queue  event  being  manipulated 

need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 

reflect  =  variable  that  stores  the  current  reflected  optical  packet 

reflect.port  =  variable  that  holds  the  current  reflection  output  port 

reflect.power  =  variable  that  holds  the  current  reflection  power 

time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 

output.pulse=  variable  that  stores  the  output  optical  packet 

output.port  =  variable  that  holds  the  output  optical  packet  port 

size=  variable  that  holds  the  number  of  events  in  the  queue 

queue.current  =  variable  that  holds  the  currently  selected  queue  event 

store  =  variable  that  holds  values  of  the  current  optical  packet 

timcLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 

e  =  elapsed  time  since  last  transition  occurred 

a  =  state  variable  that  holds  the  time  to  next  transition 

queue  =  input  container  object  to  store  the  scheduled  inputs 

queue  sizeO  =  method  that  returns  number  of  entries  in  the  queue 

queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 

queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 

queue_need_reflected()  =  method  returns  the  first  unrefiected  queue  event 

messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 

mark_refiected()  =  method  that  marks  the  current  queue  event  as  being  reflected 

update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 

insert  event  qO  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 

remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 

remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
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calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenDelayO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  J{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

caleWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  /{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  caleulates  the  optieal  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

caloReflectedQ  =  method  that  calculates  refleetion  power  of  an  optical  packet 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 

q.Vmm  =  minimum  value  in  the  queue 

v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 
InPorts  =  {“Optini”,  “OptIn2”,  “Envin”}  with 

Xm  =  {(“Optini”,  Vopt),  (“OptIn2”,  Vopt),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 
OutPorts  =  {“OptOuti”,  “OptOut2”}  with 

Ym=  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  YoptOut2)}  is  the  set  of  output  ports  and  values. 
phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower)  =  {{“passive”,  “reflect”,  “respond”, 
“update  temperature”,  propagate”}  x  Exi?  x  {“Y”,  “N”}  x  {“Y”,”N”}}; 

External  Transition  Function: 

dextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((p;,v,), . . . . 

{pn,Vn)))  = 

(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “passive”  and  p  E  {“Optini”,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
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overpower  =  “Y” 

if  calcAtten(cMrren^.v)  >  MIN_POWER 
insert_event_q(cMrrenO 
remove_event_m(cMrre«^) 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  calcAttenDelay(cwrren^.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcAttenDelay(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
interruptRespond  =  “N” 

(“respond”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  E  {“Optini”,  “OptIn2”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  eurrent.value.power  >  damaged.power 
overpower  =  “Y” 

if  oaloAtten(cMrrent.v)  >  MIN_POWER 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  —  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time.delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time.delay  =  timeLeftRespond 


(phase,  a-e,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn) 
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otherwise; 


Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  calcAttenDelay(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  oalcAttenDelay(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.xl.jcn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 
(output.port,  output.pulse) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  =  cr; 
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N.8  Mathematical  Model 


Pulse  propagation  considerations  for  the  Polarization-Maintaining  Fiber 
Module  within  the  QKD  OMNeT++  simulation  environment 


The  foHcMving  module  models  the  Panda  PM  1550  (tm)  optical  Tiber  offered  by  Coming  Incorporated 
(http  Jfwww.cQfninig.cQfn/WofkAreafshQwcontenLasp)t?id=1 8341 ) 


The  rnodute  operational  characteristics,  are  as  follows: 

‘  light  input  to  port  1  will  exit  port  2 
~  light  input  to  port  2  will  exit  port  1 

Significant  nnodification  to  the  optical  message  will  be  the  amplitude,  fo  (power) 


Pulse  Characteristics  (e.g,) 

These  pararrteters  are  used  in  the  jones  representatiotn  of  the  standard  coherent  pulse  optical 
message  packet 


,  ,  i  OOSDf 

Wsintrif'* 


Pertinent  Pulse  Characteristics  for  the  PM  Fiber  Module 


Eo  ;  electric  field  input  singal 
a  :  polarization  of  the  input  signal 

Physics 


c  ;:  =  2. S979245S  *  ID*  ot  ligbt,  a/a*} 

Pulse  Characteristics 


Aa  :=  l&SO  *  lb'*  exaaiple  central  waveleAgth  In  neters*] 

Aeo  ;=4C0*lb~^  [*  er&B^le  EVHH  of  Sausslan  pulse  shape,  units  at  secands*) 

Eln  :  =  Eo  input  power  of  Inir  (i.e.  0  dSm)  *-] 

oln  :=  a  (*  input  optical  polarlration,  units  of  radlana 

01n  ;=  4  (*  input  optical  elliptlclty,  units  of  radians  *) 


Fiber  Characterislic  (riwdeted  upon  Corning  Panda  PM  1550) 
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Z4  :=  SO  »  10^  (*  SO  kB  filter  length  et  ojcigihAl  teinperAture  Th=23C  *) 

TEC  :s  chefficient  af  thenul  l/^C  *] 

Loss  ;>0.5  (*  loss  m  tte  flter  O  l&SOnm,  dB/ltm  *) 

nFajt  :z.1.4462S  (*  fltef  Index  at  iSSOnn,  unitleza  ±> 

nSlow  :s  1.44635  (*  flter  index  along  the  slow  axis  at  Tos23C, 

1550nK,  unitleas  *) 

nT  ;*  1.2  +  10"®  t*  change  in  flter  index,  1/"C,  from  To+23c  *) 

CD  t=  17. 5 +  10'^^  (c  dhronatic  disperaion,  units  of  senonds/ (na+Jui)  *) 
CjcosaTalk4  ;=  40  {*  typical  cross-talk,  between  orthogonal 
polarizations  4  4  jneters  of  fiber  length,  units  of  -dB  •) 

CroaaTalklOO  :z  25  (*  fflaximuK  cross-talk  between  orthogonal 
polarizations  4  100  neters  of  fiber  length,  units  of  -dB  +) 

Tenplo  ;=  -40  (+  mininuiD.  operational  temperature,  degrees  eeleiua  *) 

TempEl  35  (+  DaxiBum  operational  teoperature,  degrees  celeius  *) 

Fiber  Pararmetiers  (for  use  in  following  examples  &  calculations) 

To  !=  25  (+  initial  environmental  temperature,  units  of  degrees  celeius  +) 
Tf  :=  50  (+  final  environmental  temperature,  units  of  degrees  celeius  +J 
zo  :>  100  (+  fiber  length  at  original  temperature  lo>23C,  units  of  meters  +) 

Propagation  Delay  Calculations 

Calculation  of  final  fiber  length  (giver  a  temperature  change  from  To  to  Tf) 

m  =  lO  *  TEC  (Tf  -  ToJ 
0  .001512 


zf  =  zo  +  Az 
100.002 

Calculation  of  effective  index 

An  =  nT  (Tf  -  Toj 

(tcalculates  the  change  in  refractive  index  due  to  temperature  change  +] 

0.000324 

nFastHod  >  nFast  +  An 

(+  calculates  the  temperature  modified  refractive  index  of  the  fast  axix  +) 
1 .44657 

nSlowHod  =  nSlow  *  An 

(*  calculates  the  temperature  modified  refractive  index  of  the  slow  axis  ±) 
1 .44717 

Calculation  of  Propagalion  Delay 

PsuedoCode: 

If  crin  ==  0 

n  =  nFast: 
else  if  oin  —  nf2 
n  =  nSlow; 
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else 

error  message  :  ’improper  infection  to  PM  fiber* 

end; 

Assuming  n  =  nFast 

n  :  B  nFastMod 

zf  •  n 

PropDelay  a  -  (Bflnal  timm  la  In  aaconda*) 

c 

4.82532  X 10*’ 

Assuming  n  =  nStow 

n  :  a  nSlowMod 

zf  •  n 

PzopDalay  a  -  (aflnal  tlM  la  in  aaconda*) 

c 

4.82733x10*’ 

The  same  thng.  but  in  long  form  (assuming  ain«0.  thus  n  =  nFast ) 
zo 

PropDalay  a  —  (l  ♦  TEC  (Tf  -  To) )  (nFaat  ♦  nT  (Tf  -  To) ) 
c 

4.82532  X 10-’ 

Chromatic  Dispersion  (pulse  broadenir>g)  Calculations  (not  required  for  current  model) 

Note:  Due  to  the  very  small  effect  this  has  on  our  system  due  to  the  a.)  lengths  of  fiber  being 
used  and  b.)  the  (relatively)  long  temporal  duration  and  corresponding  narrow  spectral  width, 
tMs  effect  need  not  be  included  in  the  initial  versions  of  the  OMNet'f'f  module. 

For  this  example  we  assume  the  time-power  profile  of  the  pulse  is  a  bandwidth-limited  *idear  Gaus¬ 
sian.  Thus,  the  time-frequency  barKlwidth  product  is:  Aro’Avo  =  0.441.  We  need  to  calculate  the 
spread  in  wavelength  in  the  pulse  to  calcuate  the  pulse  broadening 
Calculation  of  original  spectral  (frequency)  spread 

Avo  a  0.441  /  ACO 

(•calculates  the  frequency  FWHM  for  the  original  pulse,  units  of  Hertz*) 
1.1025x10* 

VO  a  e  /  Ao  //  N 

(•calculates  center  frequency  given  central  wavelength  Ao,  units  of  Hertz*) 
1.93414  X  10** 

Avo  *  (Ao)* 

AA  a  - (*calculates  the  spectral  FHHM,  units  In  aeters*) 

c 

8.8353x10*** 

As  can  be  seen.  AA  is  very  small,  so  we  should  expect  little  pulse  broadening  due  to  chromatic 
dispersion. 
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AX  Zt 

AcCD  >  CD  •  - * - (*  spread  due  to  chroeatic  dispersion,  units  of  seconds  *) 

10-*  1000 

1.5462  X  10-'* 


Atf  *  yj  (Aco)**  (AcCD)*  (•final  pulse  duration, 
units  of  seconds.  Note  that  the  spread  Is  so  small  over  100m  that  Its  effect 
Is  negligible  when  coe^ared  to  the  duration  of  the  original  pulse  •) 

4.  xlO-'® 


The  same  thing,  but  in  long  form 


I  !  /  1~  f  0.441 /Aco«  (Ao)* 

Atf2  m  -  I  (Aco)  *  ♦  ICD  *  - 

\  I  io-» 

4  .  X  10-'* 


Crosstalk  Calculations  (not  required  for  current  model) 

This  may  be  used,  if  desired.  Like  the  Chromatic  Dispersion  calculation,  the  effect  is  vanishingly 
small  over  short  distances,  so  we  may  not  wish  to  include  this  effect  In  the  Inital  version  of  the 
module 

Note  that  the  crosstalk  can  be  estimated  as  being  liriear  in  dB  for  fiber  above  a  few  meters  in  length. 

For  lengths  near  the  crosstalc  parameters  given  we  can  extrapolate  the  effective  crosstalk.  Note  that 
crosstalk  can  be  cyclic  and  is  effected  by  loss  in  the  fiber,  requiring  a  different,  more  accurate  mcxlel  for 
extremely  long  fiber  lengths. 

CreasTalkLevel  [Flb*rLeBghh_,  CT1_,  *1_,  CT2_,  *2_]  :■ 

/<rr2-(m\  /  fCT2-cTi\  \ 

l^rrir)  r'-  l^rrTr)  “) 

Calculation  of  the  crosstalc  level  after  transiting  the  fiber 

CroaaTAlkL*v«l[sf ,  CxoaaTalk4,  4,  CroaaTalklOO ,  100]  // 

M (•  Optical  power  of  creaatalk  algnal,  unlta  of  -dB  •) 

24.9990 


to  calculate  the  undesired  crosstalk  output  PsuedoCode: 

Ifain  »0 

aoutCT  =  x/2; 
else  if  oin  =  n/2 

ooutCT  *  0; 

else 

error  message ;  ’improper  injection  to  PM  fiber* 

end; 

Calculating  the  power  of  the  crosstalc  output: 

Eoutcrr  [FlbarL*n_,  CT1_,  sl_,  Crr2_,  *2_]  :■  Bin  *  "v/ 
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EoutCT[2.£,  CrossTAlle.4 ,  4^  CjcasaTallclOO ,  100] 
0.0562357  Eo 


Altenuation  Calculations 

Here  we  calculate  ttie  power  of  the  pulse  after  it  has  passed  through  the  full  length  of  the  fiber. 

lioas 

TotAtten  =  - *  z£ 

1000 

(*~Total  Attentuatlon"  In  unlta  of  dB.  The  'Lobs"  texai  Is  divided  by  1000 
as  thie  less  in  the  flbej:  is  in  units  of  db/km,  Hfaile  '•zf'  ia  in  meteca.  -*) 

0.0500006 

Here  we  calculate  the  amplitude  of  the  field  of  the  pulse  after  it  has  passed  through  the  lull  length  of  the 
fiber. 

Eout  =  Ein  •  10”'^“'''”'^**  (*FiMl  power,  units  of  ftatts*) 

0.9fie553Eo 

Values  used  for  output  pulse 

Ao  // M  (*  wavelength  reBaina  unchanged,  units  of  netera 

1.55  X  10'^ 

Edut  f !  H  (*  power  ia  reduced  by  TotAtten{dB)  ,  units  of  watts  «> 

0.9fia553Eo 

aout  ; =  ain 

Acf  (n-chroaatic  dispersion  leads  to  effectively  zero  teaporal  spread, 
units  of  seconds 

4  .  X  lO-^® 

FjeopD«lA.y  (*  thA  tUB«  it  taked  for  the  p-ulae  fo  trerislt.  the  tesp- 
Adjoate^  length  of  flher  along  the  epipfoi^riete  axIa,  Ia  u&itA  of  seeofidA  *) 

A  .SiSlS  X 


COTS  WcbsiLt*  iKibs: 

hUp:/AHiimA‘.L‘ortiia2^CL>n/WurkAr<ea/'s(lKm'4:i:iiELiilJBip:t?iJ~li{34l  umxJ  tur  ifii^  riMxluk*  *) 
b  Lip  ^  w .  Lburiii  bti  .cticn/N  i:  vi-C  j  luii  p  1^  X I  im J  bj  lvK  i  ruj  p_  I 1 5^ 

bLlp://iL‘L‘iri.pluru.H(M!.urg/‘d;unfi/^lum|>.jNp7lp*^mtimtH.T~1  U74K47  \  "  iim!EuL  ifulil.  riflirruEKi:  LcncL’min^  Lypoii  olMM  libcT  uiid 

pcxjpagatlMxi  *'l 


N.9  Component  Use  Case 


N.9.1  Respond  to  an  Optical  Packet  in  the  PM  Fiber 

Optical  packet  arrives  at  the  PM  fiber.  Place  the  optical  packet  into  the  optical  queue. 
Check  to  see  if  optical  packet  overpowers  the  PM  fiber.  Records  overpower  condition,  if 
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applicable.  Remove  the  optical  packet  from  the  queue  and  calculate  the  attenuated  optical  output 
signal  based  on  the  input  signal,  length  and  type  of  fiber,  and  the  current  component  state. 
Maintain  the  optical  packet  polarization.  Propagate  the  attenuated  optical  output  signal  out  of  the 
component  optical  port  that  is  not  the  same  as  the  input  port. 

•  Identified  Alternative  Uses  Cases 

o  React  to  an  environmental  message 

•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
o  Reflections  are  not  affected  by  component  state 
o  Incoming  electrical  signals  are  not  affected  by  component  state 


’'Reflections  are  not  configured  to  be  effected  by  state 
*Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  134.  Component  states. 
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state  =  <phase,  a,  store,  temperature,  overtemp,  overpower, 
interruptRespond,  queue. xl..xn} 


dint/ 

queue 

=0 


dext  OPT/ 
OPTpwr  < 
minpwr  ^ 

ta  = 

/" 

1 - ^  Passive 

A=0 

V _ ^ 

tas 

dext  ENV/  / 
check 

overtemp  , 

\ 

dext  OPT/ 
check 
overpower; 
Insert  (xl,ta); 
get  queue 
<min) 


ta  = 
time 
delay 


dextOPT/ 

update 

queue; 

insert 

(xl,ta) 


dext  ENV/ 
update  queue 
ta;  get  queue 

\/ 


Respond 
-^1  A=propagation 


ta= 

time 

delay 


tas 

time 

delay 


dint/  queue  ! 
=0;  get  queue 
(min);  set  ta 


ta  = 
time 
delay 


Figure  135.  PM  fiber  phase  transition  diagram. 

N.  9.2  Respond  to  Optical  Packet  End  Goals 


•  Optieal  paeket  entered  and  removed  from  queue  in  proper  sequenee 

•  Overpower  eondition  properly  reeognized  and  reeorded 

•  Optieal  paeket  attenuated  properly  to  the  limit  of  aeeuraey 

•  Optieal  paeket  propagated  out  the  eorreet  port  at  the  eorreet  time 

N.9.3  Respond  to  an  Environmental  Packet  in  the  PM Eiber 

Environmental  paeket  arrives  at  the  eomponent.  Cheek  to  see  if  environmental  paeket 
temperature  sets  the  eomponent  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level 
returns  eomponent  from  degraded  state  to  normal  state.  Reeords  ehange  in  eondition,  if 
applieable.  Change  eomponent  funetion  if  in  degraded  or  damaged  state. 


•  Assumptions 
o  None 


N.  9. 4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  paeket  reeeived  properly 

•  Overtemperature  eondition  properly  reeognized  and  reeorded 

•  Change  of  state  eompleted  and  reeorded  properly,  if  neeessary 

•  Change  eomponent  funetion  properly,  if  neeessary 
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N.IO  PM  Fiber  Test  Cases 


Each  optical  component  was  tested  by  sending  inputs  into  the  eomponent,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  eheck  behavior  and  timing.  Eaeh  component  had 
eaeh  of  its  input  ports  (optieal,  environmental  (env),  and/or  eontrol  (ctrl))  tested  singly,  then  in 
different  eombinations  of  ports  and  input  messages.  All  identified  errors  were  eorrected  and  the 
component  retested  until  it  funetioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  proeessing. 
Control  messages  work  in  the  same  way,  but  foree  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  paekets  foree  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  eomponent  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  aeross  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reaeting  to  inputs  as  noted  at  the  top  of  each  table.  Eaeh  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  eolumn  lists  the  total  number  of  tests 
performed  on  a  eomponent;  suceessive  columns  list  the  number  of  those  tests  that  exercise  a 
partieular  port  (optieal,  etrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  ereated  by  the  optieal 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  eomparing  the  conceptual  models  to  the  qkdX  framework. 
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Table  5.  PM  Fiber  Test  Cases 


Inject  Ports 

Running  Totals 

Phase 

Case 

Optl 

Opt2 

Env 

Notes 

opt  # 

env  # 

Passive 

1 

1 

0 

0 

single 

1 

0 

2 

0 

1 

0 

single 

2 

0 

3 

0 

0 

1 

single 

2 

1 

4 

1 

1 

0 

same  time 

4 

1 

5 

1 

1 

0 

differ  time 

6 

1 

6 

1 

1 

1 

same  time 

8 

2 

7 

1 

1 

1 

differ  time 

10 

3 

8 

0 

1 

1 

same  time 

11 

4 

9 

0 

1 

1 

differ  time 

12 

5 

10 

1 

0 

1 

same  time 

13 

6 

11 

1 

0 

1 

differ  time 

14 

7 

20 

2 

0 

0 

same  time 

16 

7 

21 

0 

2 

0 

same  time 

18 

7 

22 

2 

2 

0 

same  time 

22 

7 

23 

2 

2 

0 

differ  time 

26 

7 

24 

2 

2 

1 

same  time 

30 

8 

25 

2 

2 

1 

differ  time 

34 

9 

26 

0 

2 

1 

same  time 

36 

10 

27 

0 

2 

1 

differ  time 

38 

11 

28 

2 

0 

1 

same  time 

40 

12 

29 

2 

0 

1 

differ  time 

42 

13 

totals 

21 

21 

13 

42 

Respond 

41 

2 

0 

0 

single 

44 

13 

42 

0 

2 

0 

single 

46 

13 

43 

1 

0 

1 

single 

47 

14 

44 

2 

1 

0 

same  time 

50 

14 

45 

2 

1 

0 

differ  time 

53 

14 

46 

2 

1 

1 

same  time 

56 

15 

47 

2 

1 

1 

differ  time 

59 

16 

48 

0 

2 

1 

same  time 

61 

17 

49 

0 

2 

1 

differ  time 

63 

18 

50 

2 

0 

1 

same  time 

65 

19 

51 

2 

0 

1 

differ  time 

67 

20 

60 

3 

0 

0 

same  time 

70 

20 

61 

0 

3 

0 

same  time 

73 

20 

62 

3 

2 

0 

same  time 

78 

20 

63 

3 

2 

0 

differ  time 

83 

20 

64 

3 

2 

1 

same  time 

88 

21 

65 

3 

2 

1 

differ  time 

93 

22 
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totals 

66 

67 

68 

69 

0 

0 

3 

3 

3 

3 

0 

0 

1 

1 

1 

1 

same  time 

differ  time 

same  time 

differ  time 

96 

99 

102 

105 

23 

24 

25 

26 

36 

27 

13 

63 

TCI 

1 

0 

2 

single 

106 

28 

TC2 

1 

0 

2 

single 

107 

30 

TC3 

1 

0 

2 

single 

108 

32 

TC4 

1 

0 

2 

single 

109 

34 

TC5 

1 

0 

2 

single 

110 

36 

TC6 

1 

0 

2 

single 

111 

38 

TC7 

1 

0 

2 

single 

112 

40 

totals 

7 

0 

14 

7 

Notes:  5  -  under  minimum  power  packet  sent  on  OPTl;  OPTl  &  OPT2  -  differ  time  -  Passive 

7  -  under  minimum  power  packet  sent  on  OPT2;  OPTl,  OPT2,  ENV  -  differ  time  - 
Passive 


N.ll  References 


Coming.  (2013).  Panda  pm  speciality  optical  fibers.  Retrieved  October  8,  2013,  from 
http://www.corning.com/WorkArea/showcontent.aspx?id=18341 

OZOptics.  (2014).  Accurate  alignment  preserves  polarization 

.  Retrieved  March  31,  2014,  from  http://www.ozoptics.com/ALLNEW  PDF/ARTOOOl  .pdf 

RPPhotonics.  (2013).  RP  phontics  encylopedia  -  polarization-maintaining  fibers 
.  Retrieved  March  31,  2014,  from  http://www.rp-photonics.com/ 
polarization  maintaining  fibers.html 


452 


Appendix  O  -  Polarization  Controller  (Deterministic) 

0.1  Device  Description: 

The  polarization  controller  (PC)  is  a  device  that  changes  the  polarization  state  of  light 
that  passes  through  it,  converting  light  from  any  random  polarization  state  into  a  specific  output 
polarization  state.  A  deterministic  controller  is  computer-controlled  to  output  the  light 
automatically  without  needing  operator  inputs  during  operation.  The  device  consists  of 
polarimeter  and  a  state  of  polarization  (SOP)  controller  combined  with  a  computer  and  software. 
See  Figure  1  for  an  example  of  a  deterministic  polarization  controller. 


Figure  136.  View  of  a  deterministic  polarization  controller  (ThorLabs,  2013). 

The  Polarization  controller  is  a  bidirectional  optical  component  with  two  optical  ports 
and  computer  port.  Optical  signals  arriving  at  the  input  port  are  propagated  to  the  other  port  after 
a  defined  propagation  delay  and  the  polarization  is  changed  to  a  specific  point  on  the  Poincare 
sphere  and  then  output  through  the  other  port.  The  polarizing  system  is  sensitive  to  the  power  of 
the  optical  signals  that  are  propagated  through  the  component.  If  the  optical  power  of  a  pulse 
exceeds  a  defined  threshold,  the  polarization  controller  may  become  permanently  damaged 
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which  changes  its  propagation  characteristics.  Similarly,  the  Polarization  controller  is  sensitive  to 
the  temperature  in  the  environment  in  whieh  it  operates.  If  the  temperature  exceeds  defined 
thresholds,  the  Polarization  controller  may  become  temporarily  degraded  or  permanently 
damaged  which  changes  its  propagation  characteristics.  If  temporarily  degraded,  the  device  may 
recover  to  normal  operating  behavior  after  the  temperature  returns  to  a  “normal”  operating 
temperature. 

The  first  step  involved  with  the  modeling  the  polarization  eontroller  is  to  collect  and 
understand  the  physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this 
case,  this  information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optieal 
physies.  The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica 
software  program  that  modeled  the  Polarization  eontroller.  The  SME  developed  a  series  of  use 
cases  that  exercised  the  functionality  of  the  deviee  over  a  wide  variety  of  conditions  and  verified 
the  model  and  validated  the  input  and  output  behavior  of  the  device  within  a  single  Mathematica 
model  (worksheet).  The  Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME 
communicated  the  behavior  of  the  Polarization  controller  to  the  researcher.  Additional 
information  came  from  product  data  sheets  from  commereial  vendors  and  standard  texts  from  the 
optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the 
polarization  eontroller  using  the  DEVS  formalism.  The  bulk  of  the  document  following  this 
section  is  dedicated  to  the  detailed  development  of  the  DEVS  model  of  the  polarization 
eontroller.  Once  developed,  the  model  will  be  simulated  using  the  MS4ME  simulator  using  the 
same  uses  cases  defined  in  the  Mathematiea  worksheet.  The  SME  will  then  review  the  MS4ME 
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simulation  output  to  verify  that  the  DEVS  formal  model  matches  the  behavior  of  the 
Mathematica  model  and  hence  the  real  component. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 


Figure  137.  Symbol  for  the  polarization  controller  in  the  QKD  system  architecture. 

0.2  Polarization  Controller  Conceptual  Model 


Figure  138.  Polarization  controller  conceptual  model. 

The  conceptual  model  for  a  polarization  controller  consists  of  two  optical  input  ports 
{Opthii,  OptIn2},  two  optical  output  ports  {OptOuti,  OptOut2},  one  environmental  input  port 
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{Evnin}  and  one  electrical  controller  input  port  and  one  electrical  controller  output  port  {Ctrlln, 
CtrlOut}.  The  environmental  port  allows  external  sources  to  communicate  changes  in  the 
operational  environment  to  the  polarization  controller.  The  electrical  controller  ports  allow  for 
control  inputs  to  the  controller  and  responses  from  the  polarization  controller  to  the  higher 
system  functions. 

In  comparison  to  the  polarization  controller  symbol  used  in  the  QKD  simulation 
architecture  shown  in  Figure  2,  a  single  bidirectional  optical  connection  is  decomposed  into  an 
optical  input  and  an  optical  output  in  the  conceptual  model.  The  electrical  control  port  is  not 
shown  for  clarity  in  Figure  2,  and  is  also  decomposed  in  the  model  into  an  input  port  and  an 
output  port.  This  is  necessary  to  properly  represent  the  behavior  of  the  device  using  the  DFVS 
formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  polarization  controller,  a  small  portion 
of  the  signal  will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual 
model  decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a 
discrete  unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  3 
will  instantaneously  generate  a  reflected  emitting  out  of  OptOuti. 

The  polarization  controller  calculates  changes  to  the  amplitude,  and  polarization 
ellipticity  and  orientation  of  any  packet  coming  through  either  optical  port  after  a  time  equaling 
the  propagation  delay  of  the  module.  The  polarization  controller  determines  the  input  optical 
packet  polarization  and  changes  the  polarization  to  match  the  output  polarization  set  by  the 
control  messages  for  packets  entering  port  1  moving  in  the  forward  direction.  Packets  entering 
port  2  and  moving  in  the  reverse  direction  experience  a  change  to  the  current  polarization 
opposite  to  that  from  those  entering  port  1 .  Sufficient  time-averaged  optical  power  is  required  for 
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the  polarization  controller  to  operate  as  the  controller  has  a  minimum  optical  power  level 
threshold  necessary  to  make  changes. 

In  the  model,  every  quantum-level  pulse  is  changed  by  the  current  polarization  controller 
settings,  but  only  bright  pulses  cause  an  update  to  the  current  polarization  settings.  The  bright 
pulses  in  our  model  provide  the  sufficient  time-average  power  to  enable  the  controller  to  make 
polarization  changes.  Every  output  packet  is  calculated  at  full  power  minus  some  small  amount 
to  account  for  attenuation  (insertion  loss  and  Polarization  Dependent  Loss)  through  the  device 
and  the  ellipticity  and  orientation  are  changed  to  match  the  required  output  ellipticity  and 
orientation. 

The  polarization  controller  must  calculate  the  power  of  each  incoming  optical  signal  in 
order  to  determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This 
calculation  is  made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering, 
once  overpowered  the  device  will  permanently  change  attenuation.  External  environmental 
messages  sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the 
Polarization  controller  can  determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a 
permanent  condition).  In  either  case,  a  function  determines  how  the  propagation  changes  as  a 
function  of  the  device  state  and  current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation.  This 
greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 
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0.3  Mathematical  Model 


For  a  detailed  mathematieal  deseription  of  the  Polarization  eontroller,  refer  to  Seetion  13.8 
whieh  eontains  the  Mathematiea  worksheet  provided  by  the  optieal  physies  SME. 

0.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
Polarization  controller. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Determine  the  input  port  number. 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Place  the  optical  packet  into  the  queue 

•  Calculate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same  port  number. 

•  Retrieve  the  input  optical  signal  from  the  queue,  and  calculate  the  attenuated  output 
optical  signal  based  upon  the  input  optical  signal,  the  OverPower  flag,  the  OverTemp 
flag,  and  the  current  environment 

•  Update  the  values  of  the  input  optical  signal  based  on  the  characteristics  of  the  controller, 
the  original  values  of  the  input  optical  signal  and  the  current  environment. 

•  Send  the  changed  output  signal  out  of  the  optical  output  port  number  that  is  not  the  same 
as  the  input  port  number. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 
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When  a  control  message  arrives: 


•  Update  the  aset  and  (l)set  with  the  values  in  the  control  message 


0.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  Polarization  controller  in 
the  boxes  and  the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is 
labeled  with  the  type  of  transition  (d^,  -  external  or  d/„;  -  internal)  and  the  significant  actions  that 
take  place  during  the  transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating 
the  value  of  the  time  advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of 
the  phase  and  an  entry  showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase 
outputs.  Note  there  is  a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets 
arrive  at  the  Polarization  controller  at  the  same  time. 


State  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  currrentPolar, 
newPolar,  currentRotation,  Queue. xl..xn> 


dext  OPT/  check  overpower;  insert  (xi,ta) 


dint/ 
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ta=time 

delay 

dext 
ENV/ 
update 
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Passive 
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^dext  ENV/ 
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tasO 
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I  CTRL/  if 
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I  interrupt 
=  N 


•dint/ 
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ta) 
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^  Update 
Polarization 
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A=ctrl  msg 


dint/  interrrupt  =Y; 
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dint/  needRespond  =Y  ta=0 


tastime  delay  9^*  queue(mtn);  set  ta 


_ I 

^  ta=0 


ta=0 


dext  OPT/  update  queue  ta;  Insert  (xi,ta) 


Respond 
Aspropagation 

/^\  dint/ 
queue  1=0; 
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ta 

ta=  time 
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*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 


Figure  139.  Polarization  controller  phase  transition  diagram. 


459 


0. 6  Event-Trace  Diagram 


This  section  shows  various  examples  of  packets  entering  the  Polarization  controller.  The 
tables  list  the  states  the  polarization  controller  proceeds  through  as  the  packets  are  processed. 
Each  table  has  the  state  number,  with  each  state  consisting  of:  phase,  time  until  next  transition 
(sigma),  store  state  variable,  current  temperature  of  the  Polarization  controller,  the  over 
temperature  flag  variable  and  the  over  power  flag  variable.  The  next  column  shows  the  contents 
of  the  queue  at  that  state,  the  contents  of  the  store  state  variable  and  any  notes. 

Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Queue:  contents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 

0. 6. 1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  56.  Case  I  state  list. 
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1  packet,  0  environmental  events,  0  external  events,  0  control  events 


Figure  140.  Case  I  sequence  diagram. 

0. 6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  57.  Case  II  state  list. 
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1  packet,  0  environmental  events,  1  external  event  (with  1  packet)  at  e=2,  0  control  events 
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Figure  141.  Case  II  sequence  diagram. 

0.6.3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 


Table  58.  Case  III  state  list. 
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Figure  142.  Case  III  sequence  diagram. 

0.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 

Table  59.  Case  IV state  list. 
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Figure  143.  Case  IV  sequence  diagram. 

0,6,5  CASE  V:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Control  Packet  Arriving  at  Time  3 


Table  60.  Case  V  state  list. 


time 

state 

entry/ 

exit 

phase 

sigma 

store 

(xi) 

temp 

over 

temp 

over 

power 

interrupt 

respond 

need 

respond 

current 

polar 

queue 
(xj,  tp) 

Notes: 

assume 

tp=  5 

1  opt 

1  env 

0  opt 

1  Ctrl 

464 


0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

n 

n 

ij>,  a 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

n 

n 

ij>,  a 

(xl,5) 

0 

sl 

entry 

reflect 

0 

null 

c 

n 

n 

n 

n 

ij>,  a 

(xl,5) 

0 

sl 

exit 

reflect 

5 

xl 

c 

n 

n 

n 

n 

ij>,  a 

(xl,5) 

s2 

entry 

respond 

5 

xl 

c 

n 

n 

n 

n 

ij>,  a 

(xl,5) 

CTRL 

arrives 

e=3 

s2 

exit 

respond 

0 

xl 

c 

n 

n 

y 

n 

ij>,  a 

(xl,2) 

s3 

entry 

update 

detector 

0 

xl 

c 

n 

n 

y 

n 

ij>,  a 

(xl,2) 

s3 

exit 

update 

detector 

2 

xl 

c 

n 

n 

y 

n 

ij>,  a 

(xl,2) 

s4 

entry 

respond 

2 

xl 

c 

n 

n 

y 

n 

(j}  +,  a 

(xl,2) 

s4 

exit 

respond 

0 

xl 

c 

n 

n 

n 

n 

(j)  +,  a 

null 

s6 

entry 

passive 

inf 

xl 

c 

n 

n 

n 

n 

^  +,  a 

null 

1  packet,  0  environmental  event,  0  external  event,  1  control  event  at  e  =  3 


Passive 


dext  optical  message 


Reflect 


I — I  dint  optical  message 


I 

dint  optical  iViessage 
- 1 - 


Respond 


Update 

Polarization 


dext  control  message 


dint  control  message 


Figure  144.  Case  V  sequence  diagram. 

0. 7  Polarization  controller  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  Assume  that  only  one  control  packet  will  arrive  at  any  given  time,  due  to  the  small  time 
scales  involved  and  the  length  of  time  necessary  for  polarization  changes. 
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•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 

’’interruptRespond”,  “needRespond”,  “currentPolar”,  “newPolar”,  “currentRotation”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 

Time  delay  =  time  advance  stored  in  queue  for  event  i 

e  =  elapsed  time  since  last  transition  occurred 

“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  polarization  controller  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  8 ext,  8i„t,  8con,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp}  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  2  X  ^  5  is  the  external  state  transition  function; 

8int  =  S'  ^  S'  is  the  internal  state  transition  function; 

8con  =  0 X  X^j  Sis  the  confluent  transition  function; 

/I  =  S  ^  T*  is  the  output  function; 

ta  =  S  ^  r:u  cc  ov  S  ^  R+  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 


DEVS  Polarization  controller  (Xw,  Tm,  S,  Sgxt^  8intj  8con^  t(l) 


where 
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tp  =  transmission  time  inside  the  attenuator 
temperature  =  eurrent  temperature  of  the  attenuator 

phase  =  eontrol  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “reflect”,  “respond”,  “update  detector”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
needRespond=  flag  variable  set  when  both  Reflect  and  UpdateDetector  respond  to  inputs 
currentPolar  =  current  polarization  and  ellipticity  values  of  the  controller 
newPolar  =  polarization  the  controller  is  changing  to  after  receiving  a  change  message 
currentRotation  =  polarization  and  ellipticity  rotation  values  for  the  current  packet 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  current  optical  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optical  packet 
messagebag=  variable  that  stores  the  current  x  input  value(s)  {p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optical  power  level  parameter 

damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 

current  =  variable  that  stores  the  queue  event  being  manipulated 

need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 

reflect  =  variable  that  stores  the  current  reflected  optical  packet 

reflect.port  =  variable  that  holds  the  current  reflection  output  port 

reflect.power  =  variable  that  holds  the  current  reflection  power 

time,  delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 

output.pulse=  variable  that  stores  the  output  optical  packet 

output.port  =  variable  that  holds  the  output  optical  packet  port 

size=  variable  that  holds  the  number  of  events  in  the  queue 

ctrlOutput  =  variable  that  stores  the  output  control  message  response 

queue.current  =  variable  that  holds  the  currently  selected  queue  event 

store  =  variable  that  holds  values  of  the  current  optical  packet 

timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 

minSet  =  minimum  optical  pulse  power  necessary  for  a  change  to  output  polarization 

maxSet  =  maximum  optical  pulse  power  allowed  for  a  change  to  output  polarization 

aset  =  fixed  output  orientation  of  the  polarizer,  set  by  user 

(l)set  =  fixed  output  ellipticity  of  the  polarizer,  set  by  user 

e  =  elapsed  time  since  last  transition  occurred 

a  =  state  variable  that  holds  the  time  to  next  transition 

queue  =  input  container  object  to  store  the  scheduled  inputs 

queue_size()  =  method  that  returns  number  of  entries  in  the  queue 

queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 

queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 

queue_need_reflected()  =  method  returns  the  first  unreflected  queue  event 

messagebag_lirst()  =  method  that  returns  the  first  element  of  the  message  bag 

mark_reflected()  =  method  that  marks  the  current  queue  event  as  being  reflected 

update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 

ctrlMsgO  =  method  that  generates  a  response  message  to  received  control  messages 

outputMsgO  =  method  that  generates  the  response  message  to  received  optical  packets 

insert  event  qO  =  method  that  inserts  the  current  (x,,  time  delay,)  into  the  queue 
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remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x/,  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  /{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  j{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  output  as  J{current.v,  temperature,  overtemp, 
peakpwr,  overpwr,  currentPolar,  newPolar,  currentRotation) 
calcPolarSetO  =  method  that  calculates  the  current  polarization  setting  as  f[aset,current.v) 
calcReflectedO  =  method  that  calculates  reflection  power  of  an  optical  packet 
changePolarizationO  =  method  that  changes  current  polarization  of  the  controller 
calcAttenPolarO  =  method  that  calculates  the  optical  output  as  fpurrent.v,  temperature, 
overtemp,  peakpwr,  overpwr,  currentPolarization) 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 
q.v  =  pointer  to  a  value  in  the  queue 
q-Vmm  =  minimum  value  in  the  queue 
v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Optini”,  “OptIn2”,  “Envin”,  “Ctrlln”}  with 
Xm  =  {(“Optini”,  Vopd,  (“OptIn2”,  Vopd,  (“Envin”,  Venv),  (“Ctrlln”,  E^r/)}  is  the  set  of  input 
ports  and  values. 

OutPorts  =  {“OptOuti”,  “OptOut2”,  “CtrlOut”}  with 
Ym  =  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  Yoptouti),  (“CtrlOut”,  Yoriout)}  is  the  set  of  output 
ports  and  values. 

phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interrupt  Respond,  needRespond, 
currentPolar,  newPolar,  currentRotation,  queue)  =  {{“passive”,  “reflect”,  “respond”,  “update 

polarization”}  x  R^xVxRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  xV  xVxV 

X  V) 


468 


External  Transition  Function: 


Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond  , 
currentPolar,  newPolar,  cur  rent  Rotation,  queue,  e,  ((p„v,),....  (p„,v„)))  = 

(“reflect”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolar,  newPolar,  cur  rent  Rotation,  queue. x  1  ..xn) 
if  phase  =  “passive”  and  p  E  {“Optini”,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_lirst(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 
if  currentPolar  !=  newPolar 

currentPolar  =  ca\cPo\ar(current.v,  temperature,  overtemp,  peakpwr,  overpwr, 
currentPolar,  newPolar,  currentRotation) 

(“reflect”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolar,  newPolar,  currentRotation,  queue. x\..xn) 
if  phase  =  “respond”  and  p  E  {“Optini”,  “OptIn2”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_need_reflected() 
reflect  =  (queue. current.p),  cadcRQdQCiQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
if  currentPolar  !=  newPolar 

currentPolar  =  ca\c?o\a.r(current.v,  temperature,  overtemp,  peakpwr,  overpwr, 
currentPolar,  newPolar,  currentRotation) 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolar,  newPolar,  currentRotation,  queue. x\..xn) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
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overtemp  =  “Y” 
if  currentPolar  !=  newPolar 

currentPolar  =  c^\c?o\^x{current.v,  temperature,  overtemp,  peakpwr,  overpwr, 
currentPolar,  newPolar,  currentRotation) 


(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
needRespond,  currentPolar,  newPolar,  currentRotation,  queue.x\..xn) 
if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time. delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
if  currentPolar  !=  newPolar 

currentPolar  =  ca\c?o\a.v{current.v,  temperature,  overtemp,  peakpwr,  overpwr, 
currentPolar,  newPolar,  currentRotation) 
time. delay  =  timeLeftRespond 

(“update  polarization”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  currentPolar,  newPolar,  currentRotation,  queue.x\..xn) 
if  phase  =  “passive”  and  p  =“CtrlIn” 
ctrlOutput  =  etrlMsg(5tore) 
newPolar  =  store.value.polarization 

(“update  polarization”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  currentPolar,  newPolar,  currentRotation,  queue. x\..xn) 
if  phase  =  “respond”  and  p  =  “Ctrlln” 
update_delay(queue) 

CtrlOutput  =  otrlMsg(5tore) 
interruptRespond=  “Y” 
newPolar  =  store.value.polarization 


(phase,  a  -  e, 
otherwise; 


00,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 
currentPolar,  newPolar,  currentRotation,  queue. x\..xn) 


Internal  Transition  Function: 


dintiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolar,  newPolar,  currentRotation,  queue)= 
(“refleef’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolar,  newPolar,  currentRotation,  queue. x\..xn)) 
if  phase  =  “reflect”  and  need.reflect  !=  null 
need.reflect  =  queue_need_reflected() 
current  =  need.reflect 

if  current.value.power  >  MinSet  and  <  MaxSet 
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newPolar  =  calcPolarSet(cMrren^) 
reflect  =  (current.p),  calcReflected(cMrren^.v)) 
mark_ref[ected{current) 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interrupt  Respond, 

needRespond,  currentPolar,  newPolar,  currentRotation,  queue. x\..xn) 
if  phase  =  “reflect”  and  need.reflect  =  null 
need.reflect  =  queue_need_reflected() 
if  InterruptRespond  =  “N” 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  current.value.power  >  MinSet  and  <  MaxSet 
newPolar  =  calcPolarSet(cMrrent) 
if  InPort  =  “Optini” 

outputPulse  =  ca\c?o\av{store.v,  temperature,  overtemp,  peakpwr,  overpwr,  currentPolar, 
newPolar,  currentRotation) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcPolar(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr,  currentPolar, 
newPolar,  currentRotation) 
outputPort  =  “OptOuti” 
timeLeftRespond  =  propagation  delay 
else 

time.delay  =  timeLeftRespond 

(“update  polarization”,  0,  store,  temperature,  overtemp,  overpower,  InterruptRespond,  needRespond, 

currentPolar,  newPolar,  currentRotation,  queue. x\..xn) 
if  phase  =  “reflect”  and  needRespond  =  “Y” 
ctrlOutput  =  ctrlMsg(5tore) 

(“respond”,  time.delay,  store,  temperature,  overtemp,  overpower,  InterruptRespond, 
needRespond,  currentPolar,  newPolar,  currentRotation,  queue.x\..xn) 
if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  current.value.power  >  MinSet  and  <  MaxSet 
newPolar  =  calcPolarSet(cMrrent) 
if  InPort  =  “Optini” 

outputPulse  =  calcPolar(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr,  currentPolar, 
newPolar,  currentRotation) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcPolar(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr,  currentPolar, 
newPolar,  currentRotation) 
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outputPort  =  “OptOuti” 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolar,  newPolar,  currentRotation,  queue. x\..xn) 

if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 


(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  overpower,  interruptRespond, 
needRespond,  currentPolar,  newPolar,  currentRotation,  queue. x\..xn) 
if  phase  =  “update  polarization”  and  interruptRespond  =  “N” 


(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  overpower,  interruptRespond, 
needRespond,  currentPolar,  newPolar,  currentRotation,  queue. x\..xn) 
if  phase  =  “update  polarization”  and  interruptRespond  =  “Y” 
time. delay  =  timeLeftRespond 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
needRespond,  currentPolar,  newPolar,  currentRotation,  queue. x\..xn) 
if  phase  =  “update  polarization”  and  interruptRespond  =  “N”  and  needRespond  =  “Y” 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  current.value.power  >  MinSet  and  <  MaxSet 
newPolar  =  calePolarSet(cMrrent) 
if  InPort  =  “Optlm” 

outputPulse  =  ealePolar(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr,  currentPolar, 
newPolar,  currentRotation) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcPolar(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr,  currentPolar, 
newPolar,  currentRotation) 
outputPort  =  “OptOuti” 

Confluence  Function: 


dconis,  ta{s),  x)  =  SextiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolar,  newPolar,  currentRotation,  queue)  = 

{reflect. p,  reflect. v) 
if  phase  =  “reflect” 

{outputPort,  outputPulse) 


All 


if  phase  =  “respond” 


("CtrlOut",  ctrlOutput) 
if  phase  =  "update  polarization" 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  interrupt  Respond,  needRespond, 

currentPolar,  newPolar,  cur  rent  Rotation,  queue)  =  cr; 
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0.8  Mathematical  Model 


Pulse  propagation  considerations  for  the  Polarization  Controller  Mod 
ule  within  the  QKD  OMNet+-i-  simulation  environment 


The  Polarization  Controler  Module  operates  based  upon  optical  messages  that  are  high  in  power 
(relative  to  the  sub-single-photon  n^essages).  All  optical  messages  will  be  passed  through  the  con¬ 
troller.  However,  the  transformation  required  to  achieve  the  appropriate  output  is  determined  by  only 
the  high  power  message. 


The  operational  characteristics  are  as  follows; 

-  light  input  to  port  1  will  exit  port  2 

-  light  input  to  port  2  will  exit  port  1 

Significant  nx>difications  to  the  optical  message  will  be  the  amplitude.  Eo  (power),  eliptidty,  4,  and  the 
polarization,  a. 


Pulse  Characteristics  (e.g.) 

These  parameters  are  used  in  the  jones  representation  of  the  standard  coherent  pulse  optical 
message  packet 


E(t) 


g(f)Eo 


cosa 
I  (sina)^ 


-) 


Pertinent  Pulse  Characteristics  for  the  Polarization  Controller  Module 


Eo  :  electric  field  input  singal.  port  1 

oOuantln  :  input  polarization  of  the  input  sigr^.  port  1 

^Quantln  :  input  elipticity  of  the  input  signal,  port  1 

For  this  module  I  will  use  the  Thoriabs  Deterministic  Polarization  Controller 
(http://www.thof1abs.com/NewGroupPage9.cfm?Ob)ectGroup_IDs930&pnsDPC5500#930)  as  an 
example.  This  COTS  device  integrates  a  state  of  polarization  (SOP)  controller  with  a  digital 
signal  processor,  enabling  high  speed  control  and  selectable,  locking  output  SOP. 

InsertLoss  :>  1.2  (•  intrinsic  power  loss, 
including  connectors,  of  the  OFC  device,  units  -dB  •) 

HetLoss  :*  60  (•  isnxleuin  relative  return  power, 
signal  reflected  by  an  input  beam,  units  of  -dB  *) 

TeapH  :«  40  (•  max  operational  temperature,  units  of  ^  •) 

Tei^L  :s  5  (•  min  operational  temperature,  units  of  "C  *) 

SOPAccuracy  :>  s/720  (*  accuracy  of  locked  degree  of  polarization, 
applies  to  a  and  4t  from  spec  of  ♦/-  0.25”  on  Poincare  Sphere  *) 

MinPwr  0.01  (*  required  minimum  operational  power, 
units  of  mH,  from  spec  of  -20  dBm  *) 

MaxPwr  :*  31.6  (•  ms zinnia  operational  power, 
units  of  mH,  from  spec  of  ♦IS  dBm  *) 
aset  :>  s/2  (•  fixed  output  orienation  of  the  high- 
power  pulse/beam.  s/2  is  an  exasple  *) 

0set  :  ■  0  (•  fixed  output  elliptic! ty  of  the  high- 
power  pulse/beam.  0  is  an  example  *) 
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Amplitude  Altenuation  Calculations  for  Polarization  Controller  (Higft-power  and  Quantum  Level 
Signals) 

To  caJouiaie  ifie  output  amplitude  we  need  to  include  inserticir  lose 
JUDplltudeln  ;=  Eo 

EouttAfliplitudeIn_,  IruaertLoss_l  =  As^lltudeln  *  //  n 

P.fiTOlSfifl  Eo 

If  we  wish  lo  flag  the  controller  ta  indude  undesIred  return  (reflected)  messages,  the  follchwing  opera¬ 
tions  would  hold  true. 

ERe turn  [Affl.pl itu(lelii_,  Retl^afl_]  x  Amplitutltln*  //  h 


0.00177323  Ein 

High-Power  Polarizaion  Calculations  for  Polarization  Controller 

nHlgbln  (*  input  blgh-power  orlentAtiAn  *} 

^Bighln  (*  Input  hlgh-pomr  elllpticLty 

The  advantage  of  the  DPC  (integrated  polarization  controller  and  digital  signal  processor)  is  that  is  can 
accomodate  any  input  polarization  and  ellipbcity  and.  with  very  low  loss,  lock  the  output  polarization  of  a 
beam  (pulses)  of  suffident  power  to  a  pre-selected  state. 

aHlghOut  :x  aaet  (*  output  hlgh-power  orientation; 
oaet  Is  the  orientation  setting  of  the  polarlaeter  •) 

(jHighOut  ;=  (>set  (*■  optput  hlgh-power  elliptictty; 
i^set  Is  the  elllptlclty  setting  of  the  polarloeter  *) 


Quantum-level  Polarization  Calculations  for  Polarization  Controller 

The  polarization  controller  state  is  set  and  used  to  alter  the  high-power  frame  signals.  This  setting, 
(orientation  and  ellipticity  rotations)  used  to  alter  the  hlgh-power  signals,  will  also  be  experienced  by  the 
quantum-level  pulses.  Although  factors  such  as  birefringence  and  wavelength-dependent  polarization 
changes  can  alter  how  the  polarization  controller  rotates  the  quantum-level  signal,  we  can  use  the 
following  as  a  first  approximation; 

aQsuntOut  'X  apsuntln  +  (aset  -  aSlghln) 

^gu&ntout  i^QuantXn  +  (i^set  -  pHlghIu} 
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Example  for  an  optical  pulse  passed  through  the  Polarization  Controller  (refresh  Kernel  before 
use) 


(•  Polarixatlon  Controllar  Paraaatars  •) 

InsartLoss  :k1.2  (•  intrlaaic  powar  lose, 
iBcludlng  eoatvactors,  of  tba  DPC  davlca,  units  -dB  •) 

RatLoas  60  (*  amnlaum  ralativa  raturn  po«*ar, 
signal  raflactad  by  an  input  baaai,  units  of  -dB  *) 

SOP&ccuracy  n/720  (•  accuracy  of  lockad  dagraa  of  polarization, 
applias  to  a  and  froai  spac  of  «/-  0.25°  on  Poincara  Sphara  *) 

^arror  :*  RandoiBHaal[(SOPAccuracy,  SOPAecuracy}] 

(*  ganaratas  randnai  nuaibar  batwaan  ♦/-  SOPAccuracy,  unitlass  •) 
aarror  : *  RandosOlaal [ { SOPAccuracy ,  SOPAceuracy } ] 

(•  ganaratas  random  nuabar  batwaan  ♦/-  SOPAceuracy,  unitlass  •) 
asat  :  ■  JT  /  2 
^sat  :■  0 

aHighOut  :«asat  (•  ou^ut  high-powar  oriantation  *) 

^HigbOut  dsat  (•  op^ut  bigb-powar  allipticity  *) 

aQuantOut  :«  oQuantln  ♦  (asat- aHigbln) 

^QuantOut  :«  dQuantIn  ♦  (dsat- ^Bigbln) 

Eout[InputAaiplituda_,  InsartLoss_]  :■  InputAaplituda  *  "v/ // H 

ERatum[InputAaplituda_,  RatI.oss_]  :■  InputAaplituda  •  'sj  //  n 

(•  bigb  powar  pulsa  *) 

AaplitudaInHigb  :•  EoHigb 

oHigbln  :m  a/4  (*  assigns  positiva  diagonal  oriantation  •) 
dHigbln  a/32  (*  assigns  slight  allipticity  *) 

(•  quantum-laval  pulsa  •) 

AaplitudaInQuant  :■  EoQuant 
3  a 

aQuantIn  :«  -  (*  assignas  positiva  67.5  dagraas  oriantation  *) 

8 

OQuantln  0  (*  assigns  linaar  polarization  *) 

(•  Calculations  for  Higb-Powar  Pulsa  *) 

Eout[AaplitudaInHigb,  InsartLoss]  //  N 
ERatum[AiiplitudaInHigb,  RatLoss]  // H 
aHigbOut  //  M 
^HigbOut  //  H 

0.870964  EoHigb 
0.001  EoHigb 
1.5708 


0. 
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( *  CAleul&tldfifl  taK  Pulft«  *) 

EauttAmplitudfilnQuant,  InafcrtLcss]  It  K 
ERcturn [AmplitudelnQuant^  RetLoas]  H 
aQuAAtOufc  /  /  H 
^guuitJOut  N 

(>.S70$£4  EOQudllt 
O.OOl  EaOLiant 
1 .9635 
-0. 0901746 


Cots  lA  tbsilc  nutei: 

hL1p:/'/iAMW.llKidab3.t«n/>.fwtjraupl^ip.-9.clin'.'(JI:gLT.1titwjp_lL>^3HWtp»i— LJI\.'S5CHW930  i"  mtxldi  bails 

hLtp://uu  w.plKH.'ai.^pthuUjniL’i.ciJciV4liM:uiiiLTili/pubrLeaiiuffiL’ijniruLlLT__012U2.piJl' 

hL1p:/yu'wn'.plKii.T]Lv.phuUjniL’i.ciJcn/ss^£4Ki1i:ypnHjiKii/bli.H:PuciLiilly_L~cjnAnjllL*d_I\jlaruabun_t‘onllnjLlLTJiIiii 

hLlp:/A*ww.Liitjplicii.«jciW'ALL\LWJ*l>/DTSO(HLpd] 

hLlpiZ/uu  w.libi3lugix.uan/]^iusni:/LlLi:trLnH:alLy7n2Dail<insii.'iAi2UPularualKin°i20L'UfiIrulkr.bLinl 

hLlp:/AAV'n'.aiiiiiLili(\:ti.<:uin/p(ll7lir'\1(M]ulL'i*E'ulari£i<i(Ki7s20Nlaiia^in:Dl'Lbnajn]L'%2Urulan/abun°'ilOS(;ninblLi^^2(K.'urriiulkT.{idf 


0.9  Component  Use  Case 

0.9.1  Respond  to  an  Optical  Packet  in  the  Polarization  Controller 

Optical  packet  arrives  at  the  polarization  eontroller.  A  portion  of  optieal  paeket  refleets 
baek  down  incoming  optical  line.  Plaee  the  optieal  paeket  into  the  optical  queue.  Check  to  see  if 
optical  packet  overpowers  the  polarization  controller.  Reeords  overpower  eondition,  if 
applicable.  Remove  the  optieal  packet  from  the  queue  and  eheeks  if  it  is  a  bright  pulse.  If  a  bright 
pulse,  update  paeket  rotation  values.  Caleulate  the  attenuated  optieal  output  signal  and  rotate 
pulse  based  on  the  input  signal  and  the  eurrent  component  state.  Propagate  the  attenuated  and 
rotated  optical  output  signal  out  of  the  component  optical  port  that  is  not  the  same  as  the  input 
port. 


•  Identified  Alternative  Uses  Cases 

o  Respond  to  a  eontrol  message 
o  React  to  an  environmental  message 

•  Assumptions 
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o  Component  has  completed  initialization  sequence  at  least  once 
o  Reflections  are  not  affected  by  component  state 
o  Incoming  electrical  signals  are  not  affected  by  component  state 


Initialization 

No  Optical  Output 


Normal  State 


*Reflections  are  not  configured  to  be  effected  by  state 
^Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  145.  Component  states. 
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state  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  currPolar, 
Queue. xl..xn> 


dext  OPT/  check  overpower;  insert  (xi,ta) 


dint/ 

queue=0 


ta=time 

delay 


Passive 
A  =  0 

vdext  ENV/ 
check 
overtemp 


ta  =  0 


dext 

I  CTRL/  if 
passive 


dint/ 

I  interrupt 
=N 


•dint/ 
insert  (xi, 
ta) 


dext  CTRL/  update  queue  ta. 


dext 
ENV/ 
update 
I  queue  ta; 
\|/  set  ta 


ta=0 


dint/  interrrupt  =Y; 
needRespond  =Y;  set  ta 


^  Update 
Polarization 

msg  dint/  needRespond  =Y  ta=0 

time 
delay 

tastime  delay  get  queue(min);  set  ta 

dext  OPT/  update  queue  ta;  insert  (xi^ta) 


f  Reflect  1 

IA= reflection 
-  ■  ■  ■  ^  ta=o 


Respond 
A=propagation 

/f\  dint/ 
queue  1=0; 
get  queue 
(min);  set 
ta 

ta=  time 
delay 

•  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  146.  Polarization  controller  phase  transition  diagram. 

0.9.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  reflected  properly 

•  Optical  packet  entered  and  removed  from  queue  in  proper  sequence 

•  Overpower  condition  properly  recognized  and  recorded 

•  Polarization  rotation  values  changed  upon  receipt  of  a  bright  pulse 


Optical  packet  properly  attenuated  and  rotated  to  the  limit  of  accuracy 


•  Optical  packet  propagated  out  the  correct  port  at  the  correct  time 
0.9.3  Respond  to  an  Environmental  Packet  in  the  Polarization  Controller 
Environmental  packet  arrives  at  the  component.  Check  to  see  if  environmental  packet 
temperature  sets  the  component  to  degraded  or  damaged  state.  Check  to  see  if  temperature  level 
returns  component  from  degraded  state  to  normal  state.  Records  change  in  condition,  if 
applicable.  Change  component  function  if  in  degraded  or  damaged  state. 


•  Assumptions 

o  None 

0. 9.4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 
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•  Overtemperature  eondition  properly  reeognized  and  reeorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

0.9.5  Respond  to  a  Control  Message  in  the  Polarization  Controller 

Control  Message  arrives  at  the  component.  Component  decodes  message  properly.  Records 
change  in  condition  or  state,  if  applicable.  Change  component  function  if  in  degraded  or 
damaged  state  or  by  change  in  component  condition,  if  necessary. 

•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
0.9. 6  Respond  to  Control  Message  End  Goals 

•  Control  message  received  properly 

•  Change  of  condition  or  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

0.10  Polarization  Controller  Test  Cases 

Each  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  check  behavior  and  timing.  Each  component  had 
each  of  its  input  ports  (optical,  environmental  (env),  and/or  control  (ctrl))  tested  singly,  then  in 
different  combinations  of  ports  and  input  messages.  All  identified  errors  were  corrected  and  the 
component  retested  until  it  functioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  processing. 
Control  messages  work  in  the  same  way,  but  force  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  change 
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in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 


Table  5.  Polarization  Controller  Test  Cases. 


Phase 

Case 

Optl 

Inject  Ports 

Opt2 

Ctrl 

Env 

Notes 

Running  Totals 

opt  env  Ctrl 
#  #  # 

Passive 

1 

1 

0 

0 

0 

single 

1 

0 

0 

2 

0 

1 

0 

0 

single 

2 

0 

0 

3 

0 

0 

1 

0 

single 

2 

0 

1 

4 

0 

0 

0 

1 

single 

2 

1 

1 

same 

5 

1 

1 

0 

0 

time 

4 

1 

1 

same 

6 

1 

0 

1 

0 

time 

5 

1 

2 

differ 

7 

1 

1 

0 

0 

time 

7 

1 

2 

differ 

8 

1 

0 

1 

0 

time 

8 

1 

3 

same 

9 

1 

1 

1 

1 

time 

10 

2 

4 

differ 

10 

1 

1 

1 

1 

time 

12 

3 

5 

same 

11 

0 

1 

0 

1 

time 

13 

4 

5 

differ 

12 

0 

1 

0 

1 

time 

14 

5 

5 
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same 

13 

0 

0 

1 

1 

time 

14 

6 

6 

differ 

14 

0 

0 

1 

1 

time 

14 

7 

7 

same 

15 

1 

0 

0 

1 

time 

15 

8 

7 

differ 

16 

1 

0 

0 

1 

time 

16 

9 

7 

same 

20 

2 

0 

0 

0 

time 

18 

9 

7 

same 

21 

0 

2 

0 

0 

time 

20 

9 

7 

same 

22 

2 

1 

0 

0 

time 

23 

9 

7 

same 

23 

2 

0 

1 

0 

time 

25 

9 

8 

same 

24 

2 

0 

0 

1 

time 

27 

10 

8 

differ 

25 

2 

0 

1 

0 

time 

29 

10 

9 

same 

26 

2 

1 

1 

1 

time 

32 

11 

10 

differ 

27 

2 

1 

1 

1 

time 

35 

12 

11 

same 

28 

0 

2 

0 

1 

time 

37 

13 

11 

differ 

29 

0 

2 

0 

1 

time 

39 

14 

11 

same 

30 

0 

0 

1 

1 

time 

39 

15 

12 

differ 

31 

0 

0 

1 

1 

time 

39 

16 

13 

same 

32 

2 

0 

0 

1 

time 

41 

17 

13 

differ 

33 

2 

0 

0 

1 

time 

43 

18 

13 

totals 

27 

16 

13 

18 

Respon 

d 

41 

2 

0 

0 

0 

single 

45 

18 

13 

42 

1 

1 

0 

0 

single 

47 

18 

13 

43 

1 

0 

1 

0 

single 

48 

18 

14 

44 

1 

0 

0 

1 

single 

49 

19 

14 

same 

45 

2 

1 

0 

0 

time 

52 

19 

14 

same 

46 

2 

0 

1 

0 

time 

54 

19 

15 

47 

2 

0 

0 

1 

differ 

56 

20 

15 
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time 

differ 

48 

2 

0 

1 

0 

time 

58 

20 

16 

same 

49 

2 

1 

1 

1 

time 

61 

21 

17 

differ 

50 

2 

1 

1 

1 

time 

64 

22 

18 

same 

51 

1 

1 

0 

1 

time 

66 

23 

18 

differ 

52 

1 

1 

0 

1 

time 

68 

24 

18 

same 

60 

3 

0 

0 

0 

time 

71 

24 

18 

same 

61 

1 

2 

0 

0 

time 

74 

24 

18 

same 

62 

3 

1 

0 

0 

time 

78 

24 

18 

same 

63 

3 

0 

1 

0 

time 

81 

24 

19 

same 

64 

3 

0 

0 

1 

time 

84 

25 

19 

differ 

65 

3 

0 

1 

0 

time 

87 

25 

20 

same 

66 

3 

1 

1 

1 

time 

91 

26 

21 

differ 

67 

3 

1 

1 

1 

time 

95 

27 

22 

same 

68 

1 

2 

0 

1 

time 

98 

28 

22 

differ 

69 

1 

2 

0 

1 

time 

101 

29 

22 

totals 

43 

15 

9 

11 

TCI 

1 

0 

1 

2 

single 

102 

31 

23 

TC2 

1 

0 

1 

2 

single 

103 

33 

24 

TC3 

1 

0 

1 

2 

single 

104 

35 

25 

TC4 

1 

0 

1 

2 

single 

105 

37 

26 

TC5 

1 

0 

1 

2 

single 

106 

39 

27 

TC6 

1 

0 

1 

2 

single 

107 

41 

28 

TC7 

1 

0 

0 

2 

single 

108 

43 

28 

TC8 

1 

0 

0 

2 

single 

109 

45 

28 

totals 

8 

0 

6 

16 

s 

23  -  INIT  control  message  sent;  OPTl  &  Ctrl  -  same  time  - 
Notes:  Passive: 


25  -  Set  polarization  message  &  bright  pulse  -  OPTl  &  Ctrl  -  differ  time  -  Passive:  sent  value 
of  2.1(pol),  Pl(orient)  and  0.7(ellip)  for  bright  pulse 

26  -  Get  Polarization  control  message  sent  -  OPTl,  OPT2,  Ctrl  &  ENV  -  same  time  -  Passive: 
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should  respond  with  1.5707963,  weak  bright  pulse 

30  -  INIT  control  message  sent  -  Ctrl  &  ENV  -  same  time  -  Passive: 

46  -  Set  polarization  control  message  sent  -  OPTl  &  Ctrl  -  same  time  -  Passive:  sent  value  of  - 
2 

48  -  Get  Polarization  control  message  sent  -  OPTl  &  Ctrl  -  differ  time  -  Passive:  should 
respond  with  -2 

63  -  INIT  control  message  sent  -  OPTl  &  Ctrl  -  same  time  -  Respond: 

67  -  INIT  control  message  sent  -  OPTl,  OPT2,  Ctrl  &  ENV  -  differ  time  -  Respond: 
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Appendix  P  -  Polarization  Modulator  (PM) 

P.l  Device  Description: 

The  polarization  modulator  (PM)  is  an  abstract  component  that  represents  any  number  of 
devices  used  to  electronically  change  the  polarization  of  the  light  stream.  In  practice  there  are 
many  ways  to  accomplish  this  change  in  polarization,  or  generate  the  polarizations,  as  is  done  by 
using  four  different  lasers,  each  with  a  different  polarization.  This  research  conceptualizes  these 
devices  as  having  some  form  of  polarization  material  that  can  be  moved.  The  effect  is  to  change 
a  known  polarization  to  into  one  of  several  output  polarizations.  Unlike  a  deterministic 
polarization  controller  which  can  automatically  determine  the  input  polarization  and  make 
changes  to  produce  a  single  desired  output,  the  PM  responds  to  external  commands  to  set  the 
output  polarization  to  a  fixed  level  and  cannot  determine  the  input  polarization. 

Conceptually,  the  PM  is  an  in-line  bidirectional  optical  component  with  two  optical  ports. 
Optical  signals  arriving  at  one  of  the  ports  is  attenuated  and  polarized,  then  propagated  to  the 
other  port  after  a  defined  propagation  delay.  The  PM  is  sensitive  to  the  power  of  the  optical 
signals  that  are  propagated  through  the  component.  If  the  optical  power  of  a  pulse  exceeds  a 
defined  threshold,  the  PM  may  become  permanently  damaged  which  changes  its  attenuation 
characteristics.  Similarly,  the  PM  is  sensitive  to  the  temperature  in  the  environment  in  which  it 
operates.  If  the  temperature  exceeds  defined  thresholds,  the  PM  may  become  temporarily 
degraded  or  permanently  damaged  which  changes  its  attenuation  characteristics.  If  temporarily 
degraded,  the  device  may  recover  to  normal  operating  behavior  after  the  temperature  returns  to  a 
“normal”  operating  temperature. 

The  first  step  involved  with  the  modeling  the  PM  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  components  that  might  be  used  to 
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construct  such  a  device,  such  as  the  in-line  polarizer  and  the  electronically  variable  optical 
attenuator.  In  this  case,  this  information  was  obtained  from  Subject  Matter  Expert  (SME)  with 
expertise  in  optical  physics.  The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram 
Mathematica  software  program  that  modeled  the  PM.  The  SME  developed  a  series  of  use  cases 
that  exercised  the  functionality  of  the  device  over  a  wide  variety  of  conditions  and  verified  the 
model  and  validated  the  input  and  output  behavior  of  the  device  within  a  single  Mathematica 
model  (worksheet).  The  Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME 
communicated  the  behavior  of  the  PM  to  the  researcher.  Additional  information  came  from 
product  data  sheets  from  commercial  vendors  and  standard  texts  from  the  optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  PM  using 
the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated  to  the 
detailed  development  of  the  DEVS  model  of  the  PM.  Once  developed,  the  model  will  be 
simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  in  the  Mathematica 
worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that  the  DEVS 
formal  model  matches  the  behavior  of  the  Mathematica  model  and  hence  the  real  component. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 
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Polarization 
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Figure  147.  Symbol  for  the  PM  in  the  QKD  system  architecture. 
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P.2  PM  Conceptual  Model 
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Figure  148.  PM  conceptual  model. 


The  coneeptual  model  for  an  PM  eonsists  of  two  optieal  input  ports  {Optini,  OptIn2}, 
two  optical  output  ports  {OptOuti,  OptOut2},  one  environmental  input  port  {Evnin}  and  one 
eleetrieal  eontroller  input  port  and  one  eleetrieal  eontroller  output  port  {Ctrlln,  CtrlOut}.  The 
environmental  port  allows  external  sourees  to  eommunicate  changes  in  the  operational 
environment  to  the  PM.  The  eleetrieal  controller  ports  allow  for  eontrol  inputs  to  the  eontroller 
and  responses  from  the  PM  to  the  higher  system  functions. 

In  comparison  to  the  PM  symbol  used  in  the  QKD  simulation  arehiteeture  shown  in 
Figure  1,  a  single  bidireetional  optical  connection  is  decomposed  into  an  optical  input  and  an 
optical  output  in  the  eoneeptual  model.  The  eleetrieal  eontrol  port  is  not  shown  for  clarity  in 
Figure  2,  and  is  also  decomposed  in  the  model  into  an  input  port  and  an  output  port.  This  is 
neeessary  to  properly  represent  the  behavior  of  the  deviee  using  the  DEVS  formalism. 

When  an  optieal  signal  is  sent  to  the  input  of  the  PM,  a  small  portion  of  the  signal  will  be 
instantaneously  refleeted  baek  to  the  signal  source.  Sinee  the  eoneeptual  model  deeomposes  each 
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bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete  unidirectional 
optical  output,  this  means  that  an  optical  signal  arriving  at  Op  tin  i  in  Fig.  2  will  instantaneously 
generate  a  reflected  emitting  out  of  OptOuti . 

The  PM  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to  determine  if 
the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is  made  when 
the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once  overpowered  the 
device  will  permanently  change  attenuation.  External  environmental  messages  sent  to  the  device 
convey  the  temperature  of  the  operational  environmental  so  the  PM  can  determine  if  it  is 
degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In  either  case,  a  function 
determines  how  the  polarization,  attenuation  and  propagation  changes  as  a  function  of  the  device 
state  and  current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation.  This 
greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 

P.3  Mathematical  Model 

For  a  detailed  mathematical  description  of  the  PM,  refer  to  Section  14.8  which  contains  the 
Mathematica  worksheet  provided  by  the  optical  physics  SME. 

P.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the  PM. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to 

receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 

Initially,  this  flag  is  cleared. 
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•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  whieh  exeeed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optieal  signal  arrives: 

•  Determine  the  input  port  number. 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Plaee  the  optical  packet  into  the  queue 

•  Caleulate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same  port  number. 

•  Retrieve  the  input  optical  signal  from  the  queue,  and  ealculate  the  attenuated  output 
optieal  signal  based  upon  the  input  optical  signal,  the  OverPower  flag,  the  OverTemp 
flag,  and  the  current  environment 

•  Update  the  values  of  the  input  optical  signal  based  on  the  charaeteristics  of  the  PM,  the 
original  values  of  the  input  optieal  signal  and  the  current  environment. 

•  Send  the  ehanged  output  signal  out  of  the  optical  output  port  number  that  is  not  the  same 
as  the  input  port  number. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

When  a  control  message  arrives: 

•  Change  the  output  polarization  per  the  control  message. 

P.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  PM  in  the  boxes  and  the 
transitions  represented  by  arrows  between  the  phases.  Eaeh  transition  is  labeled  with  the  type  of 
transition  (dext  -  external  or  dmt  -  internal)  and  the  significant  actions  that  take  place  during  the 
transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  are  indicating  the  value  of  the  time 
advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase  and  an  entry 
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showing  either  no  lambda  output  funetion  for  that  phase  or  what  the  phase  outputs.  Note  there  is 
a  self-loop  transition  from  reflect  to  reflect  if  multiple  optieal  paekets  arrive  at  the  PM  at  the 
same  time. 


State  s  •(phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  currentPolarization, 
Queue. xl..xn> 


dint/ 
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update 
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I  CTRL/  if 
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sN 


*dinl/ 
insert  (xi, 
ta) 
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A=ctrl  msg 


[  Reflect  ^ 
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dint/  interrrupt  sY; 
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dint/  get  queue(min);  set  ta  ta  =  time  delay 


dext  OPT/  update  queue  ta;  insert  (xi,ta) 
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ta 
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*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  149.  PM  phase  transition  diagram. 

P.  6  Event-Trace  Diagram 


This  section  shows  various  examples  of  packets  entering  the  PM.  The  tables  list  the  states 
the  PM  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state  number,  with 
each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state  variable,  current 
temperature  of  the  PM,  the  over  temperature  flag  variable  and  the  over  power  flag  variable.  The 
next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents  of  the  store  state  variable 
and  any  notes. 

Explanations  for  each  column: 


•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 
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•  Sigma;  the  time  until  next  internal  transition.  A  0  sigma  indieates  a  transitory  state 

•  Store;  eontents  of  the  store  variable  for  that  state 

•  Temp;  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp;  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power;  shows  the  value  of  the  over  power  flag  variable 

•  Queue;  contents  of  the  queue  for  that  state 

•  Notes;  any  notes  for  that  state 

P.  6. 1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 


Table  61.  Case  I  state  list. 
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Figure  150.  Case  I  sequence  diagram. 

P.  6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 


Table  62.  Case  II  state  list. 
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Figure  151.  Case  II  sequence  diagram. 

P.6.3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 


Table  63.  Case  III  state  list. 
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Figure  152.  Case  III  sequence  diagram. 

P.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 


Table  64.  Case  IV  state  list. 
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Figure  153.  Case  IV  sequence  diagram. 

P.6.5  CASE  V:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Control  Packet  Arriving  at  Time  3 


Table  65.  Case  V  state  list. 
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1  packet,  0  environmental  event,  0  external  event,  1  control  event  at  e  =  3 


Passive 


dext  optical  message 


Reflect 


I — '  dint  optical  message 


I 

dint  optical  ^essage 
- 1 - 


Respond 


Update 

Polarization 


dext  control  message 


dint  control  message 


Figure  154.  Case  V  sequence  diagram. 

P.  7  PM  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  Assume  that  only  one  control  packet  will  arrive  at  any  given  time,  due  to  the  small  time 
scales  involved  and  the  length  of  time  necessary  for  attenuation  changes. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”, 
“overpower’V’interruptRespond”,  “needRespond”,  “currentPolarization”,queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 
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“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  PM  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  dext,  Sint,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp)  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp]  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  2  ^  ^  “S'  is  the  external  state  transition  function; 

Sint  =  S'  ^  S'  is  the  internal  state  transition  function; 

Scon  =  2 X  XIj  Sis  the  confluent  transition  function; 

=  S  ^  y*  is  the  output  function; 
ta  =  S  ^  00  or  S  ^  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  PM  {Xm^  Ymj  S,  Sext^  Sint^  Scotit  tU) 
where 

tp  =  transmission  time  inside  the  attenuator 
temperature  =  current  temperature  of  the  attenuator 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “reflect”,  “respond”,  “update  detector”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
needRespond=  flag  variable  set  when  both  Reflect  and  ElpdateDetector  respond  to  inputs 
currentPolarization  =  current  polarization  of  the  PM 

attenpower  =  variable  the  holds  the  attenuated  power  of  the  current  optical  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optical  packet 
messagebag=  variable  that  stores  the  current  x  input  value(s)  {p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optical  power  level  parameter 

damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 

current  =  variable  that  stores  the  queue  event  being  manipulated 

need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 

reflect  =  variable  that  stores  the  current  reflected  optical  packet 

reflect.port  =  variable  that  holds  the  current  reflection  output  port 
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reflect.power  =  variable  that  holds  the  eurrent  refleetion  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optieal  paeket 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
ctrlOutput  =  variable  that  stores  the  output  control  message  response 
queue.current  =  variable  that  holds  the  currently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
attenuationMin  =  minimum  selectable  attenuation 
attenuationMax  =  maximum  selectable  attenuation 
e  =  elapsed  time  since  last  transition  occurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  scheduled  inputs 
queue_size()  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_reflected()  =  method  returns  the  first  unrefiected  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refiected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
ctrlMsgO  =  method  that  generates  a  response  message  to  received  control  messages 
outputMsgO  =  method  that  generates  the  response  message  to  received  optical  packets 
insert  event  qO  =  method  that  inserts  the  current  (x,,  time  delay,)  into  the  queue 
remove_event_q()  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  fiptore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  j{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  ficurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  /{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  /{current.v,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReflectedO  =  method  that  calculates  reflection  power  of  an  optical  packet 
changePolarizationO  =  method  that  changes  current  polarization  of  the  PM 
calcAttenPolarO  =  method  that  calculates  the  optical  output  as  /{current.v,  temperature, 
overtemp,  peakpwr,  overpwr,  currentPolarization) 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 
q.v  =  pointer  to  a  value  in  the  queue 
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q.Vmm  =  minimum  value  in  the  queue 
v.q  =  value  from  a  queue  entry 


Every  dgxt  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Optini”,  “OptIn2”,  “Envin”,  “Ctrlln”}  with 
Xm  =  {(“Optini”,  Vop^),  (“OptIn2”,  Vop^),  (“Envin”,  Venv),  (“Ctrlln”,  Vctrd)  is  the  set  of  input 
ports  and  values. 

OutPorts  =  {“OptOuti”,  “OptOut2”,  “CtrlOut”}  with 
Ym  =  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  Yoptouti),  (“CtrlOut”,  Yctriout)}  is  the  set  of  output 
ports  and  values. 

phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interrupt  Respond,  needRespond, 
currentPolarization,  queue)  =  {{“passive”,  “reflect”,  “respond”,  “update  polarization”}  x 
Exi?  X  {“Y”,  “N”}  X  {“Y”,”N”}  X  {“Y”,”N”}  x  {“Y”,”N”}  xV  xV) 

External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond  , 

currentPolarization,  queue,  e,  ((p;,v,), . . . .  (p„,v„)))  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolarization,  queue. xl .  .xn) 

if  phase  =  “passive”  and  p  E  {“Optini”,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue. first(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolarization,  queue. x\..xn) 

if  phase  =  “respond”  and  p  E  {“Optini”,  “OptIn2”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
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if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrenO 
remove_event_m(cMrrenO 
queue. current  =  queue_need_reflected() 
reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolarization,  queue. x  \ ..xn) 

if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  currentPolarization,  queue. x\..xn) 

if  phase  =  “respond”  and  p  —  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time. delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

(“update  polarization”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  currentPolarization,  queue.xl.jcn) 

if  phase  =  “passive”  and  p  =“CtrlIn” 
ctrlOutput  =  ctrlMsg(5tore) 
currentPolarization  =  store. value. polarization 

(“update  polarization”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  currentPolarization,  queue.xl.jcn) 


if  phase  =  “respond”  and  p  —  “Ctrlln” 
update_delay(queue) 

CtrlOutput  =  otrlMsg(5tore) 
interruptRespond=  “Y” 
currentPolarization  =  store. value. polarization 


(phase,  a  -  e, 
otherwise; 


00,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolarization,  queue. x  \ ..xn) 
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Internal  Transition  Function: 


Sintiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolarization,  queue)= 

(“reflect”,  0,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolarization,  queue.xl ..xn)) 

if  phase  =  “reflect”  and  need.reflect  !=  null 
need.reflect  =  queue_need_reflected() 
current  =  need.reflect 

reflect  =  (current.p),  calcReflected(cMrrent.v)) 
mark_reflected(cMrrent) 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  currentPolarization,  queue.xl.. xn) 

if  phase  =  “reflect”  and  need.reflect  =  null 
need.reflect  =  queue_need_reflected() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  calcAttenPolar(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcAttenPolar(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
timeLeftRespond  =  propagation  delay 
else 

time.delay  =  timeLeftRespond 

(“update  polarization”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  currentPolarization,  queue.xl.. xn) 
if  phase  =  “reflect”  and  needRespond  =  “Y” 
ctrlOutput  =  ctrlMsg(5tore) 

(“respond”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  currentPolarization,  queue. xl..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  calcAttenPolar(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcAttenPolar(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr) 
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outputPort  =  “OptOuti” 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolarization,  queue. x  \ ..xn) 

if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  overpower,  interruptRespond, 

needRespond,  currentPolarization,  queue.xl.jcn) 
if  phase  =  “update  polarization”  and  interruptRespond  =  “N” 

(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  overpower,  interruptRespond, 

needRespond,  currentPolarization,  queue.xl.jcn) 
if  phase  =  “update  polarization”  and  interruptRespond  =  “Y” 
time,  delay  =  timeLeftRespond 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  currentPolarization,  queue.xl.jcn) 
if  phase  =  “update  polarization”  and  interruptRespond  =  “N”  and  needRespond  =  “Y” 
current  =  queue_min() 
time.delay  =  eurrent.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  calcAttenPolar(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcAttenPolar(5tore.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

currentPolarization,  queue)  = 

(reflect. p,  reflect. v) 
if  phase  =  “reflect” 

(outputPort,  outputPulse) 
if  phase  =  “respond” 

("CtrlOut",  ctrlOutpuf) 
if  phase  =  "update  polarization" 

0  (null  output) 
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otherwise; 


Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  interrupt  Respond,  needRespond, 

currentPolarization,  queue)  =  cr; 

P.  8  Mathematical  Model 

Below  is  the  math  model  for  the  in-line  polarizer.  The  polarization  modulator  works  in  mueh  the 
same  way  with  the  addition  of  a  control  port  to  allow  the  output  polarization  angle  (a)  to  be 
changed  during  operation. 
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Pulse  propagation  considerations  for  the  In-line  Polarizer  Module 
within  the  QKD  OMNet-f+  simulation  environment 

The  in-line  fiber  polarizer  is  destgned  to  pass  one  potarizalioni  of  light  wtiiis  blocking,  witti  significanl 
extinction,  light  with  a  polarization  orthogonal  to  that  of  the  passed  polarization.  This  design  can  be 
used  to  convert  un  polarized  (or  any  random  polarization  or  eliptidly)  into  highly  polarized  UghL  It  can 
also  be  used  to  increase  the  extinction  ratio  of  polarized  signaJs.  Note  that  COTS  devices  are  available 
with  either  polarization-maintainirtg  or  single-mode  liber  pigtais.  In  the  case  of  polarization-maintaining 
fiber,  the  polarizing  angle  (y)  wll  be  aligrred  with  one  of  the  two  guiding  axes  of  the  fiber.  For  sirrgle- 
mode  fiber  there  is  no  prefTered  axis  of  transmission  as  it  is  (ideally)  cylindrically  symmetric.  Thus,  for 
the  single-mode  case,  we  will  refer  to  y  as  the  angle  above  the  laboralory  positive  horizontal  (x)  axis. 

The  operational  characteristics  are  as  follows; 

-  light  input  to  port  1  will  exit  port  2 

-  light  input  to  port  2  will  exit  port  1 

Significant  modifications  to  the  optical  message  will  be  the  amplitude,  Eo  (power),  elipticity,  and  the 
polarization,  a. 

Pulse  Characteristics  (e.g.) 

These  parameters  are  used  in  the  jones  representation  of  the  standard  coherent  pulse  optical 
message  packet 

Pertinent  Pulse  Characteristics  for  the  In-Line  Polarizer  Module 

Eo :  electric  field  input  singaJ,  port  1 
a  :  polarization  of  the  input  signal,  port  1 
4  :  elipticily  of  the  input  signal,  port  1 

The  following  parameter  values  are  examples  of  typical  Isolators  and  are  taken  from  COTS 
devices  offered  by  the  Newport  corporation  (http;f^www.newponcom/Flber-Optlc-ln-Line-Polartz- 
ers/84d607f1033i/info.a&px#tab_Speclflcations).  Note  that  I  have  use  the  single-mode  fiber  pig- 
tailed  version's  |>arameters. 

Extlnctiofilt&lo  44  (•  typt.cal  relative  poweif 
emitted  fceniL  the  undesljced.  pelajcization ,  units  oZ  -dB 
znsettusB  ‘sO.5  (*  Mmini im  peMsf  loss  given  an  insertion 
polsrlzetlon  on  the  pref fared  axis,  units  -dB 
RetLoss  :<  (*  ituixl niiii  relative  return  power, 

signal  reflected,  by  an  Input  beaat,  units  of  -dB  •) 

TeopH  :>  70  (*  aax  operational  teeiperature ,  units  of  °C  *} 

Tempi.  :  >  0  (*  nln  operational  teaperature ,  units  of  °C  x) 

HaxPwr  3P0  Baxlmun  operational  power,  units  of  uN 

Amplitude  Attenuation  Calculations  for  In-Line  Polarizer 

Polarizalion-based  atleruabon  must  be  included  in  the  calculation.  LeTs  first  define  our  optical  vector, 
as  it  wll  be  used  to  illustrate  a  few  examples; 
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optv*et  ; 


.  A**""!"*-) 


/  Coa[a]  I 

I  Sin [aj  J 


Here,  A  is  the  input  amplitude,  a  is  the  polarization,  and  ^  is  Ihe  elliptidly. 


For  the  case  of  single-nnode  fiber  pigtails  we  use  the  horizontal  lab  frame  as  y=0  (vertical  as 

where  y  can  be  any  value  [0  ;  x(2).  For  the  case  of  polarizaliorwTiaintaining  fi  ber  pigtails,  y  will  have  the 

values  of  only  0  or  xtl.  In  either  case,  the  tranformation  matrix  is, 


FblnJCiZfti^  iv  ] 


(Ce,A[Y]>* 

(Ce,*trl  .Sintir]) 


(Cafl  lY]  *S±ntvj) 
(Sin[vJ)^ 


To  calculate  the  output  amplitude  we  first  want  to  account  for  the  insertion  loss 


Eteiqp[Aii^litude_,  IrLaertlonI.OAS_] 


:  X  Anplitude  * 


Here  we  use  the  aforementioned  insertion  loss  of  -0.5  dB  and  the  input  amplitude  Eo 

EAfterlnautLCies  EteopfA,  Ins^tLoas] 

0.444061  A 

We  now  have  to  calculate  the  effective  amplitude  of  the  electric  field  after  the  light  has  passed  through 
the  potarizer.  This  is  accomplished  by  taking  the  norm  of  the  vector  produced  by  operalirrg  the  polariza¬ 
tion  matrix  on  ihe  optical  vector; 

EouttTf_]  »  [v]  .OptVfect]  f  f  Fulls  1  mpllfy 

Ab3  [caa  [a]  Co3  [y]  Sin[y]]  A  Conjugate  [A]  Co3h[Z  Inify]  ] 

If  we  wish  to  flag  the  attenuator  to  include  undesIred  return  (reflected)  messages,  the  foUowing  opera¬ 
tions  would  hold  true, 

Eout[ElJi_,  Eln  *  V 10 ^ 


Examples  For  Amplitude  Attenuation  In  the  In-Line  Polarizer 

As  an  example,  let's  take  the  polarizer  and  input  polarization  to  be  oriented  in  Ihe  same,  positive  diago¬ 
nal  (45°)  with  no  elipticity; 

r  JT,  ji 

Eout|^  -  /  FullSlaqjliiy 

Ab3[A) 

As  it  should  be,  the  only  loss  in  the  first  example  is  due  to  insertion  loss,  which  Is  not  included  here  for 
illustrative  purposes.  To  include  insertiort  loss,  simply  define  the  amplitude  A  to  be  EAft&rln^ftLoss, 
I.e., 
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r  j»,  * 

Eout  — I  /.a-»  —  /  .0-»O/.A-*  EAf  t*rIn8*rtI.oss  //  FullSiapllfy 

^  4  ^  4 

0.944061  Abs(A] 

As  a  second  examp4e.  again  exduding  insertion  loss,  let*  s  keep  the  potarizer  and  input  polarization  at 
the  same  angle,  but  make  the  light  circular  (a  =  x/4.  ^  =  nfl).  Insertion  loss  is  not  included  hereafter  for 
the  sake  of  clarity; 

[jf ,  jf  n 

—  I  /.  a-*  —  /  .  ♦-*  —  //  FullSlnnlify  //  H 

4 1  4  2 

0.707107  Aba[A] 

Because  the  polarization  'rotates*,  a  power  factor  of  1A2  will  be  lost  ( 1/ v^Tin  the  amplitude).  Because 
the  light  is  circular,  the  orientation  of  the  polarizer  won't  effect  the  output  amplitude,  even  if  perpendicu¬ 
lar  to  the  initial  input  'polarization’, 

,3^1  n  n 

Eout  -  /.o-»-/.  ♦-»-//  FUllSiilpllfy  //  N 

I  4  I  4  2 

0.707107  AbsfA] 

The  same  doesn't  hold  true  for  elliptically  polarized  light  In  the  plot  below,  I  change  a  to  making  the 
light  slightly  eliptical.  I  vary  the  polarizer  angle  y  from  0  to  t; 

[n  n 

Eout  [t]  /.o-»— /.♦-♦— {T>0,jr},  Fraao  -♦  True, 

3  4 

PlotRenge  -»  (0,  1),  FrweT  whel  -*  Ct",  ”Eout  (units  of  A)”}] 


r 


This  plot  is  fun  to  play  with.  Note  what  happens  when  you  have  circular  light  (a=x/4,  krwar  light 

(a  =  arty  angle.  ^  =  0)  or  arty  eliptical  light  (vary  a  or  ^). 

As  a  final  example,  let's  put  the  polarizer  angle  at  horizontal  (y  =  0),  but  change  the  input  polarization  to 
vertical,  with  rto  elipticity 

ft 

Eout[0]  /.a-»  —  /  .^-»0//  FullSisqplify 
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This  is  idealized,  as  the  devices  typically  cal  for  an  extinction  ratios  of  -30  to  *40  dB. 

Pobrizaion  Calcubtions  for  ln>Line  Polarizer 

In  al  cases,  the  light  exiting  the  polarizer  will  be  nearly  pure  (within  the  tolerances  set  by  the  extinction 
ratio)  in  the  axis,  y,  of  the  polarizer.  Thus,  for  all  cases. 

OutputPol  :  B  T 


Pinal  Example  for  an  optical  pulse  passed  through  the  In-Line  Polarizer  (refresh  Kernel  before  use) 


InsertLoss  :«  0.5 
OptVect(a_,  ♦_)  :■ 


A  ‘1 


t  Co8[oJ 
I  Sin  [a] 


Polarizer  [ir_] 


/  (CoalT])*  {Cos(y]  *SinIr]) 
I  (Co8[y]  .Sin[yJ)  (Sin[y])» 


EouttT_,  a_,  ♦_]  «  , iior«(Polarizar  [y]  .OptVact[a,  4]]  //  FullSinplify 

0. 944061  Abs  [cos  [a]  Cos[y)  ■^e**Sin[a]  Sin[Y)]  -.'A  Conjugate  (A)  Cosh[2  Im[y]] 

In  the  example  below,  I  have  assigned  the  polarizer  angle  to  be  just  above  horizontal  (y  =  with  the 
light  polarized  at  positive  diagor^al  (a  =  x/4)  with  a  slight  elipticity  =  x/32) 

IX  X  X  , 

,  ^1  //FullSinplify 
16  4  52  f 

0.764435  Abs(A] 


X 

OutputPolariztion  ■  — 
16 
X 

16 

OutputEllipticity  ■  0 
0 


The  form  of  the  output  optical  pulse  given  the  above  parameters  would  be. 

Cos  ( OuputPolarization ) 

Sin  (OutputPolarization)  e  •Ouiiiu£»p««*y 


E(t) 

E(t) 


E(t)  -[£*]  =  OutpuAmplitude  r'*! 
=  I  j  =  0.784435*A*(  e* 

=  ( I'  j  =  0.784435* A*(  e“*-  *  e*  *)( 


j  CosIt/16] 

H  Sinlx/16jr'*® 
0.980785  \ 
19509  I 


in  other  words. 

AmplitudeOut  =  0.784435  *  Amplitudein 

<<x>Out  =  (<x>ln 
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WOut  =  (An 

aOut  =  ^/16 

=  0 

<.  ( >  i  S  cbaMc  nuict: 

.lhurbln.i.'ucn/ocv»OTuup(uw*^.clm  ’ubjcflj!ruu|>_ul~5V22 
hltpJ/w  wv»  .ncwpurt.i'um/h  ib«.T-<  )plic-lii-Lun>I\)lari/iT>/S4‘*(i07/1033Anloj»|>\(*liib_Sp<.vilicalioo» 
bUpJ/vt  w»  .u/o|Hit».ootn/ALLN  h  W  _Pl)h/I)  I SOO I K. pill 

P.9  Component  Use  Case 

P.9.1  Respond  to  an  Optical  Packet  in  the  Polarization  Modulator  (PM) 

Optical  packet  arrives  at  the  polarization  modulator.  A  portion  of  optieal  paeket  reflects  back 
down  incoming  optical  line.  Plaee  the  optieal  paeket  into  the  optieal  queue.  Cheek  to  see  if 
optical  packet  overpowers  the  polarization  modulator.  Reeords  overpower  eondition,  if 
applieable.  Remove  the  optieal  paeket  from  the  queue  and  ehange  its  polarization  based  on 
eurrent  eomponent  state.  Caleulate  the  attenuated  optieal  output  signal  based  on  the  input  signal 
and  the  eurrent  eomponent  state.  Propagate  the  attenuated  optieal  output  signal  out  of  the 
eomponent  optieal  port  that  is  not  the  same  as  the  input  port. 


•  Identified  Alternative  Uses  Cases 

o  Respond  to  a  eontrol  message 
o  Reaet  to  an  environmental  message 

•  Assumptions 

o  Component  has  completed  initialization  sequenee  at  least  onee 
o  Reflections  are  not  affeeted  by  component  state 
o  Ineoming  eleetrieal  signals  are  not  affeeted  by  component  state 
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Initialization 

No  Optical  Output 


[• 

ormal  Stal 

pected  Optia 

L. 

Output 

Under  degraded 
temperature  or 
power  threshold 


LJ. 


Degraded  State 

Reduced  Optical 
Output 


Over  damaged 
temperature  or 
power  threshold 


Damaged  State 

No  Optical  Output 


Over  damaged 
temperature  or 
power  threshold 


•Reflections  are  not  configured  to  be  effected  by  state 
•Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  155.  Component  states. 


state  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  currentPolarization, 
Queue. xl..xn> 


(text  OPT/  check  overpower;  insert  (xi,ta) 


dint/ 

queue^O 


ta=time 

delay 


Passive 
A  =  0 

t^dext  ENV/ 
check 
overtemp 


ta  =  0 


dext 
CTRL/  If 
passive 


dint/ 
interrupt 
=  N 


•dint/ 
insert  (xi, 
ta) 


\/ 


dext  CTRL/  update  queue  ta. 


dext 
ENV/ 
update 
queue  ta; 
set  ta 


ta=o  ^  Update 

Polarization 

— ctrljnsg^^  dint/  needRespond  =Y  ta=0 


T 


A=?e'^&nL _ 

^  "'A' 


ta  = 
time 


Respond 

A=propagation  - 


dint/  interrrupt  =Y; 
needRespond^Y;  set  ta  [delay 


dint/  get  queue(min);  set  ta  tastime  delay 


ta=0 


dext  OPT/  update  queue  ta;  insert  (xi,ta) 


dint/ 

queue  1=0; 
get  queue 
(min);  set 
ta 

ta=  time 
delay 

*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  156.  PM  phase  transition  diagram. 

P.  9.2  Respond  to  Optical  Packet  End  Goals 


•  Optical  packet  reflected  properly 

•  Optical  packet  entered  and  removed  from  queue  in  proper  sequence 

•  Overpower  condition  properly  recognized  and  recorded 

•  Optical  packet  properly  attenuated  and  rotated  to  the  limit  of  accuracy 
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•  Optical  packet  propagated  out  the  eorrect  port  at  the  eorrect  time 

P.  9.3  Respond  to  an  Environmental  Packet  in  the  Polarization  Modulator  (PM) 

Environmental  paeket  arrives  at  the  eomponent.  Check  to  see  if  environmental  packet 
temperature  sets  the  component  to  degraded  or  damaged  state.  Check  to  see  if  temperature  level 
returns  component  from  degraded  state  to  normal  state.  Records  change  in  condition,  if 
applicable.  Change  component  funetion  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

P.  9.4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 

•  Overtemperature  condition  properly  recognized  and  reeorded 

•  Change  of  state  completed  and  recorded  properly,  if  neeessary 

•  Change  eomponent  function  properly,  if  neeessary 

P.IO  Polarization  Modulator  Test  Cases 

Each  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  eheek  behavior  and  timing.  Eaeh  component  had 
each  of  its  input  ports  (optical,  environmental  (env),  and/or  control  (ctrl))  tested  singly,  then  in 
different  combinations  of  ports  and  input  messages.  All  identified  errors  were  eorrected  and  the 
component  retested  until  it  functioned  properly  for  each  test  ease. 

To  test  an  optieal  port,  an  optical  message  is  injected  into  that  port  when  the  eomponent 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  processing. 
Control  messages  work  in  the  same  way,  but  foree  the  component  to  begin  behavior  to  react  to 
the  eontents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  ehange 
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in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 


Table  6.  Polarization  Modulator  Test  Cases. 


Phase 

Case 

Optl 

Inject  Ports 

Opt2  Ctrl 

Env 

Notes 

Running  Totals 
opt  #  env  #  Ctrl  # 

Passive 

1 

1 

0 

0 

0 

single 

1 

0 

0 

2 

0 

1 

0 

0 

single 

2 

0 

0 

3 

0 

0 

1 

0 

single 

2 

0 

1 

4 

0 

0 

0 

1 

single 

2 

1 

1 

5 

1 

1 

0 

0 

same  time 

4 

1 

1 

6 

1 

0 

1 

0 

same  time 

5 

1 

2 

7 

1 

1 

0 

0 

differ  time 

7 

1 

2 

8 

1 

0 

1 

0 

differ  time 

8 

1 

3 

9 

1 

1 

1 

1 

same  time 

10 

2 

4 

10 

1 

1 

1 

1 

differ  time 

12 

3 

5 

11 

0 

1 

0 

1 

same  time 

13 

4 

5 

12 

0 

1 

0 

1 

differ  time 

14 

5 

5 

13 

0 

0 

1 

1 

same  time 

14 

6 

6 

14 

0 

0 

1 

1 

differ  time 

14 

7 

7 

15 

1 

0 

0 

1 

same  time 

15 

8 

7 

16 

1 

0 

0 

1 

differ  time 

16 

9 

7 

20 

2 

0 

0 

0 

same  time 

18 

9 

7 

21 

0 

2 

0 

0 

same  time 

20 

9 

7 

22 

2 

1 

0 

0 

same  time 

23 

9 

7 

511 


23 

2 

0 

1 

0 

same  time 

25 

9 

8 

24 

2 

0 

0 

1 

same  time 

27 

10 

8 

25 

2 

0 

1 

0 

differ  time 

29 

10 

9 

26 

2 

1 

1 

1 

same  time 

32 

11 

10 

27 

2 

1 

1 

1 

differ  time 

35 

12 

11 

28 

0 

2 

0 

1 

same  time 

37 

13 

11 

29 

0 

2 

0 

1 

differ  time 

39 

14 

11 

30 

0 

0 

1 

1 

same  time 

39 

15 

12 

31 

0 

0 

1 

1 

differ  time 

39 

16 

13 

32 

2 

0 

0 

1 

same  time 

41 

17 

13 

33 

2 

0 

0 

1 

differ  time 

43 

18 

13 

totals 

27 

16 

13 

18 

Respon 

d  41 

2 

0 

0 

0 

single 

45 

18 

13 

42 

1 

1 

0 

0 

single 

47 

18 

13 

43 

1 

0 

1 

0 

single 

48 

18 

14 

44 

1 

0 

0 

1 

single 

49 

19 

14 

45 

2 

1 

0 

0 

same  time 

52 

19 

14 

46 

2 

0 

1 

0 

same  time 

54 

19 

15 

47 

2 

0 

0 

1 

differ  time 

56 

20 

15 

48 

2 

0 

1 

0 

differ  time 

58 

20 

16 

49 

2 

1 

1 

1 

same  time 

61 

21 

17 

50 

2 

1 

1 

1 

differ  time 

64 

22 

18 

51 

1 

1 

0 

1 

same  time 

66 

23 

18 

52 

1 

1 

0 

1 

differ  time 

68 

24 

18 

60 

3 

0 

0 

0 

same  time 

71 

24 

18 

61 

1 

2 

0 

0 

same  time 

74 

24 

18 

62 

3 

1 

0 

0 

same  time 

78 

24 

18 

63 

3 

0 

1 

0 

same  time 

81 

24 

19 

64 

3 

0 

0 

1 

same  time 

84 

25 

19 

65 

3 

0 

1 

0 

differ  time 

87 

25 

20 

66 

3 

1 

1 

1 

same  time 

91 

26 

21 

67 

3 

1 

1 

1 

differ  time 

95 

27 

22 

68 

1 

2 

0 

1 

same  time 

98 

28 

22 

69 

1 

2 

0 

1 

differ  time 

101 

29 

22 

totals 

43 

15 

9 

11 

TCI 

1 

0 

1 

2 

single 

102 

31 

23 

TC2 

1 

0 

1 

2 

single 

103 

33 

24 

TC3 

1 

0 

1 

2 

single 

104 

35 

25 

TC4 

1 

0 

1 

2 

single 

105 

37 

26 

TC5 

1 

0 

1 

2 

single 

106 

39 

27 

TC6 

1 

0 

1 

2 

single 

107 

41 

28 

TC7 

1 

0 

1 

2 

single 

108 

43 

29 

512 


TC8 

1 

0 

1 

2  single 

109 

45 

30 

totals 

8 

0 

8 

16 

23  -  INIT  control  message  sent;  OPTl  &  Ctrl  -  same  time  -  Passive:  downstream  received 
Notes:  packets  =  214 


25  -  Set  H  control  message  sent  -  OPTl  &  Ctrl  -  differ  time  -  Passive:  downstream  received 
packets  =  207,  sent  value  of  2.1 

26  -  Set  V  control  message  sent  -  OPTl,  OPT2,  Ctrl  &  ENV  -  same  time  -  Passive:  downstream 
received  packets  =  207,  sent  value  of  4,  exceeds  PI 

27  -  Set  A  control  message  sent  -  OPTl  &  Ctrl  -  differ  time  -  Passive:  downstream  received 
packets  =  207,  sent  value  of  1 

30  -  INIT  control  message  sent  -  Ctrl  &  ENV  -  same  time  -  Passive:  downstream  received 
packets  =  214 

46  -  Set  D  control  message  sent  -  OPTl  &  Ctrl  -  same  time  -  Passive:  downstream  received 
packets  =  207,  sent  value  of  -2 

48  -  Set  angle  control  message  sent  -  OPTl  &  Ctrl  -  differ  time  -  Passive:  downstream 
received  packets  =  207,  sent  value  of  4.5 

50  -  Get  angle  control  message  sent  -  OPTl  &  Ctrl  -  differ  time  -  Passive:  downstream 
received  packets  =  207,  should  return  PI 

63  -  INIT  control  message  sent  -  OPTl  &  Ctrl  -  same  time  -  Respond:  downstream  received 
packets  =  211 

67  -  INIT  control  message  sent  -  OPTl,  OPT2,  Ctrl  &  ENV  -  differ  time  -  Respond:  downstream 
received  packets  =  207 


P.ll  References 


None 
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Appendix  Q  -  Polarizing  Beamsplitter 


Q.l  Device  Description: 


The  polarizing  beamsplitter  (PBS)  is  an  optical  device  used  to  split  a  beam  of  light  into 
two  orthogonally  polarized  outputs,  or  to  combine  two  input  streams  into  one  output  stream.  In  a 
“free-space”  beamsplitter,  light  from  one  input  fiber  is  sent  through  a  collimating  lens,  then  split 
into  two  orthogonal  states  and  focused  on  the  output  port  lenses.  Fiber-only  beamsplitters  exist, 
but  are  wavelength-dependent  and  used  in  situations  where  the  optical  fiber  carries  a  single 
wavelength.  Polarization  maintaining  fibers  are  used  on  the  main  output  ports  and  are  aligned  to 
maintain  the  polarization  supplied  by  the  splitter.  See  Figure  1  for  orientation  diagram. 


Figure  157.  Standard  orientation  of  polarization  maintaining  fibers  on  a  PBS  (OZOptics,  2013). 

A  PBS  can  be  made  from  housing  with  collimating  lenses  and  some  form  of  a  beam 

splitting  material,  usually  a  partially  reflective  mirror,  which  splits  the  light  (Saleh  &  Teich, 
1991)  or  can  be  fashioned  from  two  triangular  birefringent  materials  glued  together.  Physical 
designs  include  cubes  mounted  into  brackets  for  free-space  optics  and  housings  that  have 
permanently  mounted  pigtails  or  connectors  for  fiber  lines.  The  amount  of  light  directed  to  each 
port  depends  on  the  polarization  of  the  incoming  light.  For  example,  in  Figure  1  horizontal  light 


input  to  Port  T  will  pass  through  the  device,  with  a  very  small  amount  passed  to  Port  2.  Vertical 
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light  entering  Port  T  will  pass  to  Port  2  with  a  very  small  amount  passing  to  Port  1.  In  the 
speeifie  ease  of  diagonal  or  antidiagonal  light  50%  of  the  power  with  be  passed  to  each  port.  See 
Figure  1  for  an  example  of  a  four  port  fiber-based  PBS. 


Pigtail  Style  T«M>-by4wo  Splitter 

Figure  158.  View  of  a  two  by  two  polarizing  beamsplitter  (OZOptics,  2013). 

Although  PBS  may  have  from  three  to  eight  or  more  ports,  this  research  will  use  the  four 
port  PBS  devices  with  fiber  pigtails,  per  the  discussion  with  the  SME. 

The  PBS  is  a  bidirectional  optical  component  with  four  optical  ports.  Light  entering  the 
primary  port  is  split  to  exit  two  output  ports  with  the  splitting  ratio  dependent  on  the  polarization 
of  the  incoming  light.  In  the  opposite  direction,  the  component  works  the  same  way,  splitting  the 
light  by  passing  through  a  portion  of  the  beam  and  reflecting  the  rest  to  the  port  opposite  the 
reflected  port  used  by  the  primary  path.  The  light  suffers  both  a  slight  attenuation  from  the 
material  of  the  device  and  the  splitting  medium  has  a  phase  effect  for  the  reflected  portion  of  the 
beam.  The  reflected  beam  undergoes  a  global  phase  shift  of  nil  and  is  applied  to  light  passing 
through  the  device  in  both  directions. 

The  internal  material  is  sensitive  to  the  power  of  the  optical  signals  that  are  propagated 
through  the  component.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold,  the  PBS  may 
become  permanently  damaged  which  changes  its  propagation  characteristics.  Similarly,  the  PBS 
is  sensitive  to  the  temperature  in  the  environment  in  which  it  operates.  If  the  temperature  exceeds 
defined  thresholds,  the  PBS  may  become  temporarily  degraded  or  permanently  damaged  which 
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changes  its  propagation  characteristics.  If  temporarily  degraded,  the  device  may  recover  to 
normal  operating  behavior  after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  the  modeling  the  PBS  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica  software 
program  that  modeled  the  PBS.  The  SME  developed  a  series  of  use  cases  that  exercised  the 
functionality  of  the  device  over  a  wide  variety  of  conditions  and  verified  the  model  and  validated 
the  input  and  output  behavior  of  the  device  within  a  single  Mathematica  model  (worksheet).  The 
Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME  communicated  the 
behavior  of  the  PBS  to  the  researcher.  Additional  information  came  from  product  data  sheets 
from  commercial  vendors  and  standard  texts  from  the  optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  PBS  using 
the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated  to  the 
detailed  development  of  the  DEVS  model  of  the  PBS.  Once  developed,  the  model  will  be 
simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  in  the  Mathematica 
worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that  the  DEVS 
formal  model  matches  the  behavior  of  the  Mathematica  model  and  hence  the  real  component. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 
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2 


Figure  159.  Symbol  for  the  4-port  PBS  in  the  QKD  system  arehiteeture. 

Q.2  Polarizing  Beamsplitter  Conceptual  Model 


Envin 

Optlrii 
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OptOut2 
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Polarizing  i 

Beamsplitter 

OptOut 

OptOuti 

W' 

Optln4 

Optln3 

k 

▼ 

OptOut3 

Figure  160.  PBS  eoneeptual  model. 

The  eoneeptual  model  for  a  PBS  eonsists  of  four  optieal  input  ports  {Optini,  OptIn2, 
OptIn3,  OptIn4},  four  optieal  output  ports  {OptOuti,  OptOut2,  OptOuts,  OptOut4},  and  one 
environmental  input  port  {Evnin} .  The  environmental  port  allows  external  sourees  to 
eommunieate  ehanges  in  the  operational  environment  to  the  PBS.  In  eomparison  to  the  PBS 
symbol  used  in  the  QKD  simulation  arehiteeture  shown  in  Figure  3,  a  single  bidireetional  optieal 
eonneetion  is  deeomposed  into  an  optieal  input  and  an  optieal  output  in  the  eoneeptual  model. 
This  is  neeessary  to  properly  represent  the  behavior  of  the  deviee  using  the  DEVS  formalism. 
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When  an  optical  signal  is  sent  to  the  input  of  the  PBS,  a  small  portion  of  the  signal  will 
be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model  decomposes 
each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  4  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  PBS  calculates  changes  to  the  power  (attenuation)  of  any  packet  coming  through  an 
optical  port  after  a  time  equaling  the  propagation  delay  of  the  module.  The  packet  is  calculated  at 
full  power  minus  some  small  amount  to  account  for  attenuation  through  the  device.  The  model 
splits  each  incoming  optical  packet  into  a  ‘passed’  packet  and  a  ‘reflected’  (the  DEVS  code  in 
Section  1.7  uses  ‘strong’  and  ‘weak’),  with  the  strength  of  each  packet  determined  by  the  packet 
polarization,  and  injects  these  packets  into  the  queue.  Each  of  these  entries  are  a  (port,  value) 
pair,  just  as  any  other  entry  into  the  queue,  with  the  [port]  entry  equal  to  the  output  port  and  the 
[value]  equal  to  the  adjusted  values  of  the  incoming  packet.  Additionally,  packets  output  on  the 
reflected  port  have  %I2  added  to  their  global  phase  (i.e.  0  =  0  +  nil)  due  to  reflection  off  of  the 
beamsplitting  material  inside  the  device.  The  outputs  will  be  in  a  state  determined  by  their 
polarization,  in  the  case  of  Eigure  1,  packets  input  on  Port  T  and  exiting  Port  1  will  be  in  the  state 
(a=0,  (j)=0),  packets  exiting  Port  2  will  be  in  the  state  (a=  7i  /2,  0  =  0). 

The  PBS  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to  determine 
if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is  made  when 
the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once  overpowered  the 
device  will  permanently  change  attenuation.  External  environmental  messages  sent  to  the  device 
convey  the  temperature  of  the  operational  environmental  so  the  PBS  can  determine  if  it  is 
degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In  either  case,  a  function 
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determines  how  the  propagation  changes  as  a  function  of  the  device  state  and  current 
temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation.  This 
greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 

Q.3  Mathematical  Model 

For  a  detailed  mathematical  description  of  the  PBS,  refer  to  Section  15.8  which  contains  the 
Mathematica  worksheet  provided  by  the  optical  physics  SME. 

Q.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the  PBS. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Determine  the  input  port  number. 

•  Immediately  calculate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same 
port  number. 

•  Remove  the  packet  from  the  queue  and  split  it  into  two  packets 

•  Update  the  values  for  one  packet  as  a  ‘strong’  optical  signal  based  on  the  characteristics 
of  the  PBS,  the  original  values  of  the  input  optical  signal  and  the  current  environment  and 
set  the  correct  output  port. 
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•  Update  the  values  for  the  other  paeket  as  a  ‘weak’  optical  signal  based  on  the 
characteristics  of  the  PBS,  the  original  values  of  the  input  optical  signal  and  the  current 
environment  and  set  the  correct  output  port. 

•  Send  the  attenuated  output  signal  out  of  the  optical  output  port  number  that  is  not  the 
same  as  the  input  port  number. 

When  an  environmental  message  arrives: 

•  Update  the  Current! emp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 


Q.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  PBS  in  the  boxes  and  the 
transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled  with  the  type  of 
transition  {Aext  -  external  or  Amt  -  internal)  and  the  significant  actions  that  take  place  during  the 
transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value  of  the  time 
advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase  and  an  entry 
showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs.  Note  there  is 
a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the  PBS  at  the 
same  time. 
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state  =  {phase,  o,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  161.  PBS  phase  transition  diagram. 

Q.6  Event-Trace  Diagram 

This  section  shows  various  examples  of  packets  entering  the  PBS.  The  tables  list  the 
states  the  PBS  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state  number, 
with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state  variable, 
current  temperature  of  the  PBS,  the  over  temperature  flag  variable  and  the  over  power  flag 
variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents  of  the  store 
state  variable  and  any  notes. 

Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Queue:  contents  of  the  queue  for  that  state 
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•  Notes;  any  notes  for  that  state 

Q.  6.1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  66.  Case  I  state  list. 


Notes: 
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Figure  162.  Case  I  sequence  diagram. 

Q.  6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  67.  Case  II  state  list. 


Notes: 
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Figure  163.  Case  II  sequence  diagram. 

Q,6,3  CASE  HI:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 


Table  68.  Case  III  state  list. 
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Figure  164.  Case  III  sequence  diagram. 

Q.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 


Table  69.  Case  IV  state  list. 
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Figure  165.  Case  IV  sequence  diagram. 

Q.  7  Polarizing  Beamsplitter  Parallel  DEVS  Code 


Notes; 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
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Definitions: 


State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  PBS  we  define: 

Parallel-DEVS  atomic  M=  {Xm,  Ym,  S,  Sext,  Sint,  Scon,  to) 

Where: 

Xm  =  {{p,v)  I  p  G  InPorts,  v  G  Xp}  is  the  set  of  input  ports  and  values; 

Ym  =  {(p,v)  I  p  G  OutPorts,  v  G  Yp]  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  0  X  XIj  ^  S'  is  the  external  state  transition  function; 

Sint  =  S  ^  S  is  the  internal  state  transition  function; 

Scon  =  2  X  ^  S  is  the  confluent  transition  function; 

=  S  ^  T*  is  the  output  function; 
to  =  S  ^  U  00  or  S  ^  ,  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  to}^)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  PBS  (X/vf,  Im>  S,  Sext^  Sinty  Scorn  -^9 
where 

tp  ~  transmission  time  inside  the  attenuator 
temperature  =  current  temperature  of  the  attenuator 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “reflect”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  current  optical  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optical  packet 
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messagebag=  variable  that  stores  the  eurrent  x  input  value(s)  {p,v) 

damaged.power  =  variable  that  holds  the  eomponent  damaged  optieal  power  level  parameter 
damage,  temp  =  variable  that  holds  the  eomponent  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  refleeting 
reflect  =  variable  that  stores  the  eurrent  refleeted  optieal  paeket 
reflect.port  =  variable  that  holds  the  eurrent  refleetion  output  port 
reflect.power  =  variable  that  holds  the  eurrent  reflection  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
queue.current  =  variable  that  holds  the  currently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
e  =  elapsed  time  since  last  transition  occurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  scheduled  inputs 
queue  sizeO  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_reflected()  =  method  returns  the  first  unrefiected  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refiected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update_delay()  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
insert  event  qO  =  method  that  inserts  the  current  (x,,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  f{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPassedO  =  method  that  calculates  the  optical  packet  high  power  output  as  f  current,  v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcReflectedO  =  method  that  calculates  the  optical  packet  low  power  output  as /{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  fcurrent.v,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReflectedO  =  method  that  calculates  reflection  power  of  an  optical  packet 
MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 
q.v  =  pointer  to  a  value  in  the  queue 
q-Vmm  =  minimum  value  in  the  queue 
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v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Optini”,  “OptIn2”,  “Optins”,  “OptIn4”,  “Envin”}  with 
Xm  =  {(“Optlm”,  Vopd,  (“OptIn2”,  Vopd,  (“OptIn3”,  Vopd,  (“OptIn4”,  Vopd,  (“Envin”,  is 

the  set  of  input  ports  and  values. 

OutPorts  =  {“OptOuti”,  “OptOut2”,  “OptOuts”,  “OptOut4”}  with 
Ym  =  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  Yoptouti),  (“OptOut3”,  Yoptouts),  (“OptOut4”,  Yoptoutd)} 
is  the  set  of  output  ports  and  values. 

phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower  interruptRespond,  queue)  = 
{{“passive”,  “reflect”,  “respond”}  x  R^x  VxRx{‘X’\  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  F} 

External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((p;,v,), . . . . 

(Pn,Vn)))  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  E  {“Optini”,  “OptIn2”,  “OptIn3”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_first(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “respond”  and  p  E  {“Optini”,  “OptIn2”,  “OptInS”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_need_reflected() 
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reflect  =  {queue. current.p),  c&\cRs:^[QCiQd{queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  —  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time. delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

{phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn) 
otherwise; 

Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“refleet”,  0,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn)) 
if  phase  =  “refleet”  and  need.reflect  !=  null 
need.reflect  =  queue_need_refleeted() 
current  =  need.reflect 

reflect  =  {current.p),  ealeRefleeted(cMrrent.v)) 
mark_refleeted(cMrrent) 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
queue. x\..xn) 

if  phase  =  “refleet”  and  need.reflect  =  null 
need.reflect  =  queue_need_reflected() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
time.delay  =  eurrent.time. delay 

if  current.p  =  “Optini”  /*  input  port  1  -  strong  4  weak  3  */ 

newl  =  (“OptOut3”,ealePassed(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
new2  =  (“OptOut4”,caleRefleeted(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
else 

if  current.p  =  “OptIn2”  /*  input  port  2  -  strong  3  weak  4  */ 
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newl  =  (“OptOut4”,calcPassed(cMrren^.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
new2  =  (“OptOut3”,calcReflected(cMrren^.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

else 

if  current.p  =  “0ptln3”  /*  input  port  3  -  strong  2  weak  1  */ 

newl  =  (“OptOuti”,ealePassed(cMrrent.v,  temperature,  over  temp,  peakpwr,  overpwr)) 
newl  =  (“0pt0ut2”,caleRefleeted(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
else  /*  input  port  4  -  strong  1  weak  2*/ 

newl  =  (“0pt0ut2”,ealePassed(cMrrent.v,  temperature,  over  temp,  peakpwr,  overpwr)) 
newl  =  (“OptOuti”,ealeRefleeted(cMrre«t.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
timeLeftRespond  =  propagation  delay 
else 

time_delay  =  timeLeftRespond 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  eurrent.time. delay 

if  current.p  =  “Optini”  /*  input  port  1  -  strong  4  weak  3  */ 

newl  =  (“0pt0ut3”,ealePassed(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“0pt0ut4”,ealeRefleeted(cMrrent.v,  temperature,  over  temp,  peakpwr,  overpwr)) 
else 

if  current.p  =  “0ptln2”  /*  input  port  2  -  strong  3  weak  4  */ 

newl  =  (“0pt0ut4”,calePassed(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“0pt0ut3”,caleRefleeted(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

else 

if  current.p  =  “0ptln3”  /*  input  port  3  -  strong  2  weak  1  */ 

newl  =  (“OptOuti”,ealePassed(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“0pt0ut2”,caleRefleeted(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
else  /*  input  port  4  -  strong  1  strong  2*/ 

newl  =  (“OptOut2”,oaloPassed(cMrrent.v,  temperature,  over  temp,  peakpwr,  overpwr)) 
newl  =  (“OptOuti”,oaloRefleoted(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 
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(reflect. p,  reflect. v) 
if  phase  =  “reflect” 

(newl.p,  newl.v) 
if  phase  =  “respond” 

(newl.p,  newl.v) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

ta(phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  =  cr; 
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Q.8  Mathematical  Model 


Pulse  propagation  considerations  for  the  Polarizing  Beam  Splitter 
Module  within  the  QKD  OMNet+-l-  simulation  environment 


The  polarizing  beam  splitter  is  a  device  desigr>ed  lo  separate  ortftoganal  components  of  light, 
passing  those  orthogonal  polarization  components  into  independent  channels.  This  design  will  also 
convert  unpdarized  (or  any  rarKtom  polarization  or  eliptidty)  into  highly  polarized  light  Note  that 
COTS  devices  are  available  wiHi  either  polarization-maintaining  or  single-mode  fiber  input  (port  1 ) 
pigtails. 

For  our  purposes,  we  wil  consider  single-mode  fiber  inputs  (port  1  and  port  2).  with  polarizatioiv 
maintaining  fiber  outputs  (port  3  and  4). 

The  operational  characteristics  are  as  follows: 

-  light  input  lo  port  1  wMI  exit  port  3  and/or  port  4 

•  light  input  to  port  2  will  exit  port  3  and/or  port  4 

-  light  input  lo  port  3  wMI  exit  port  1  and/or  port  2 

•  light  input  lo  port  4  will  exit  port  1  and/or  port  2 


Significant  modifications  to  the  optical  message  will  be  the  amplitude  (power)  Eo,  eliplictty  4.  and 
the  polarization  a. 


Pulse  Characteristics  (e.g.) 

These  parameters  are  used  in  the  jones  representation  of  the  standard  coherent  pulse 
optical  message  packet. 


Pertinent  Pulse  Characteristics  for  the  Polarizing  Beam  Splitter  Module 

Eo :  electric  field  input  singal.  port  1 
o  :  polarization  of  Ihe  input  signal,  port  1 
4 :  elipticity  of  the  input  signal,  port  1 


The  following  parameter  values  are  an  example  of  a  polarizing  beam  splitter  and  are  taken 
from  a  COTS  device  offered  by  the  Oz  Optics,  ltd. 

(http://www.ozoptics.eom//ILLNEW_POF/DTS0095.pdf).  Specifically,  this  model  will  follow 
the  polarizing  beam  splitter  p/n  FOBS-12P-111-9/125-SPP-1550-PBS-40-XXX-3-1. 

This  beam  splitter  has  a  Coming  SMF-28  fiber  ir«put  with  polarization  maintaining  (PM)  fiber 
outputs 

Ext.inctionRatio  :  ■  23  (*  typical  ralativa  powwr  passed  through 
and  esiittad  frosi  tba  undasirad  polarization,  units  of  -dB  •) 
MinEatinctionRatio  :•  20  (*  sMisisnim  ralativa  powar  passed  through 
and  eoiittad  froai  the  undasirad  polarization,  units  of  -dB  •) 

InsartLoss  :■  1.0  (*  ■svimiiw  powar  loss  given  an  insertion 
polarisation  on  the  praf farad  axis,  units  -dB  «) 

RatLoss  :■  40  (•  masi wsb  ralativa  return  powar, 
signal  raflactad  by  an  input  beast,  units  of  -dB  •) 
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Amplitude  Attenuation  and  Polariztion  Calculations  for  Polarizing  Beam  Splitter 


Example  Initial  Conditions. 

Evaluate  this  cell  to  see  the  results  for  a  given  input  polarization:  do  not  evaluate  this  cel  if  you  wish 
to  see  the  general  forms  of  the  following  functions : 

a  :•  >r  /  4 

e  :•  0 
e  :•  0 


Optv»ct[o_, 


e_]  :•  gEo 


/  Cos [a]  \ 

I  Sin [a]  s**  ) 


We  define  the  horizontal  lab  frame  as  y=0  (vertical  as  y=x/2).  The  folowing  chart  describes  the 
behavior  of  the  four-port  beam  splitter. 


Input  Port 
1 
2 

3 

4 


Passed  Polarization  Reflected  Polarization  ' 
4(y  =  0)  3{y=jr/2) 

3(y  =  0)  4{y=rr/2) 

2(y  =  0)  l{y  =  n/2) 

l(y  =  0)  2(y  =  a/2) 


Note  here  that  ‘reflection*  refers  to  the  behavior  of  the  opitcal  beam  impinging  upon  the  beam 
splitter;  it  does  not  refer  to  reflection  in  the  opposite  in  direction  from  and  on  the  same  flber  as  that 
of  the  input  optical  beam.  For  the  orthogonal  output  polarizations,  y  will  be  used  to  determine  the 
output  polarization.  0  and  jt/2  for  the  output  ports.  The  second,  additive  term  is  to  indude  the  non  • 
ideality  of  the  polarizing  beam  splitter  -  K  allows  a  smal  portion  of  the  power,  set  by 
‘ExtirKtionRatio*,  to  be  passed  through  in  the  *blocked*  polarization. 


Polsrlxsr [y_] 

4^' 


(Cos  (y]  )  *  (Cos  (y]  .  Sin  [t]  ) 

(Cos  [y]  *  Sin  [y]  )  (Sin  [y]  )  » 

(Sin[y])*  (-Cos[y]  *Sin[Y]) 

Cos[y]  .Sin[y])  (Cos[y])* 


/lO 


Note  that  outputs  at  port  3  and  port  4  wil  be  propagating  through  PM  fiber.  As  such.  Ihe  two 
orthogonal  polarizations  wil  propagate  at  distinct  vetodbes.  ar>d  should  be  treated  as  irtdependent 
opical  messages. 

The  case  below  is  for  an  input  at  port  1.  Note  also  that  the  ‘refleded*  portion  of  the  beam  incurs  a 
x/2  phase  shift. 

Folowing  cases  wil  have  outputs  hidden  (remove  the  before  the  *=*  to  un-hide  outputs). 
Eout3inpatl  [a_,  e_]  • 

yj  polsrizsr  [s  /  2]  .OptVsct[a,  4,0*n/2]  // MatrixFoza 

Eout4inputl  [a_,  e_]  • 

-\j Polsrizsr[0]  .OptVsctfa,  0,  0]  //  lUtrisFor* 

I  0. 0630957  e*(J**>****^EogCos(a]  | 
io. 891251  e*<***)*‘^*****EogSin[a]  j 
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Ttie  case  balow  is  for  an  input  at  port  2.  Nolo  also  that  tha  'rofloclod'  portion  of  lha  Paam  incurs  a 
atl  phasa  shifL 


Ec»ut3iijput2[ci_,  a_]  PDLoj:iz:«r(D]  [n*  O] 

EDut.4inp«t2[a_.  a_]  PDLaj:iz:«r(w  /  2]  .  OptV»ct  {a  ,  tt. 


Note  that  optical  messages  input  to  the  Potarizing  Beam  Spitter  on  port  3  and  port  4  can  only  be, 
as  a  first  approximation,  linearly  potarized  (eilhar  horizontal  (i:r=C)  or  vertical  (a-  =  ff/2))  as  they  have 
propagaiad  through  PM  fiber. 

The  case  below  is  for  an  input  at  port  3.  Note  that  the  ’raDeoted’  portion  of  lha  beam  incurs  a  xt2 
phase  shift 

Ecmtliiiput3[(i_,  e_]  ^  PaLjuriEBr (;t  /  2]  .C^tVKt:(a,  a  *  Ji  /  2] 

Emjt2iniHit3[a:_,  e_]  PDlaiiE«r[D]  .OptVK:t[n,  <t>.  a] 

The  case  below  is  for  an  input  at  port  4.  Note  that  the  'refleoted'  portion  of  lha  beam  incurs  a  xtl 
phase  shift 

EQutlii]put*[ci_,  e_]  '^10'^“"''^““®  PDlajriz:«ir(D]  .OptVK:t[n,  *,  a] 

ECTut2iijput4[ci_,  a_]  PDlojriz:«r(w  /  2]  .pptVKt:(a,  (f,  B  ♦  h  /  2] 


If  we  wish  to  flag  lha  Polarizing  Beam  Spliller  to  indude  undasirad  return  (raftacted)  massages, 
lha  fbllowing  operations  would  hold  true, 

Erctium  [RatJ^osa _ ]  «  .pptVi»ct[a,  fl] 


1 

Caa  [aj  }  ,  f  Eo  g  Sin  [a]  }  } 

IQD  ^  ^  J  I  J  J 


COTS  Website  aaicK'. 

hltpjyft'w^-.mBpt«.cDiii/ALIJ^EW_PDF/DTS 

hUpc//A'vrA'.ibarlahsxDin^irwgraiipp^c9xriii?obJcclgraiip_id~3l6l 

liltpc//ii.‘w«‘.tlHrlah£X[]fn^fn^gjaup|iae.i*9xfni?i:ibji:irt^raiip_icHM73  tkate  tlial  this  dcsicc  uuss.  j.  dilTsrciii  method  ta  iplil 
alhogcHiaJ  pobrkatkms,  tfic  abcnY  phyuca]  dcscripticHis  wculd  not  bald 


Q.9  Component  Use  Case 


Q.9.1  Respond  to  an  Optical  Packet  in  the  Polarizing  Beam  Splitter  (PBS) 

Optical  packet  arrives  at  the  PBS.  A  portion  of  optical  packet  reflects  back  down 
incoming  optical  line.  Place  the  optical  packet  into  the  optical  queue.  Check  to  see  if  optical 
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packet  overpowers  the  PBS.  Records  overpower  condition,  if  applicable.  Remove  the  optical 
packet  from  the  queue  and  create  a  reflected  and  transmitted  packet.  Calculate  the  attenuated 
optical  output  signal  based  on  the  input  signal,  the  output  port  and  the  current  component  state. 
Propagate  the  attenuated  optical  output  signals  out  of  the  component  optical  ports  based  on  the 
input  port  and  whether  transmitted  or  reflected. 

•  Identified  Alternative  Uses  Cases 

o  React  to  an  environmental  message 

•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
o  Reflections  are  not  affected  by  component  state 
o  Incoming  electrical  signals  are  not  affeeted  by  component  state 


Under  c 
temper; 
power  t 


*Reflections  are  not  configured  to  be  effected  by  state 
•Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  166.  Component  states. 
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state  =  {phase,  o,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  167.  PBS  phase  transition  diagram. 

Q.  9.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  reflected  properly 

•  Optical  packet  entered  and  removed  from  queue  in  proper  sequence 

•  Overpower  condition  properly  recognized  and  recorded 

•  Optical  packet  attenuated  properly  to  the  limit  of  accuracy 

•  Optical  packet  propagated  out  the  correct  port  at  the  correct  time 

Q.9.3  Respond  to  an  Environmental  Packet  in  the  Polarizing  Beam  Splitter  (PBS) 

Environmental  packet  arrives  at  the  component.  Check  to  see  if  environmental  packet 
temperature  sets  the  component  to  degraded  or  damaged  state.  Check  to  see  if  temperature  level 
returns  component  from  degraded  state  to  normal  state.  Records  change  in  condition,  if 
applicable.  Change  component  function  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

Q.  9. 4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 

•  Overtemperature  condition  properly  recognized  and  recorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 
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•  Change  component  function  properly,  if  necessary 

Q.IO  PBS  Test  Cases 

Each  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  check  behavior  and  timing.  Each  component  had 
each  of  its  input  ports  (optical,  environmental  (env),  and/or  control  (ctrl))  tested  singly,  then  in 
different  combinations  of  ports  and  input  messages.  All  identified  errors  were  corrected  and  the 
component  retested  until  it  functioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  processing. 
Control  messages  work  in  the  same  way,  but  force  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 
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Table  5.  PBS  Test  Cases 


Running 

Inject  Ports 

Totals 

Phase 

Case 

Optl 

Opt2 

Opts 

Opt4 

Env 

Notes 

opt  # 

env  # 

Passive 

1 

1 

0 

0 

0 

0 

single 

1 

0 

2 

0 

1 

0 

0 

0 

single 

2 

0 

3 

0 

0 

1 

0 

0 

single 

3 

0 

4 

0 

0 

0 

1 

0 

single 

4 

0 

5 

0 

0 

0 

0 

1 

single 

4 

1 

6 

1 

1 

1 

1 

0 

same  time 

8 

1 

7 

1 

1 

1 

1 

0 

differ  time 

12 

1 

8 

1 

1 

1 

1 

1 

same  time 

16 

2 

9 

1 

1 

1 

1 

1 

differ  time 

20 

3 

10 

0 

1 

0 

0 

1 

same  time 

21 

4 

11 

0 

1 

0 

0 

1 

differ  time 

22 

5 

12 

1 

0 

0 

0 

1 

same  time 

23 

6 

13 

1 

0 

0 

0 

1 

differ  time 

24 

7 

14 

0 

0 

1 

0 

1 

same  time 

25 

8 

15 

0 

0 

1 

0 

1 

differ  time 

26 

9 

16 

0 

0 

0 

1 

1 

same  time 

27 

10 

17 

0 

0 

0 

1 

1 

differ  time 

28 

11 

20 

2 

0 

0 

0 

0 

same  time 

30 

11 

21 

0 

2 

0 

0 

0 

same  time 

32 

11 

22 

0 

0 

2 

0 

0 

same  time 

34 

11 

23 

0 

0 

0 

2 

0 

same  time 

36 

11 

24 

2 

2 

2 

2 

0 

same  time 

44 

11 

25 

2 

2 

2 

2 

0 

differ  time 

52 

11 

26 

2 

2 

2 

2 

1 

same  time 

60 

12 

27 

2 

2 

2 

2 

1 

differ  time 

68 

13 

28 

0 

2 

0 

0 

1 

same  time 

70 

14 

29 

0 

2 

0 

0 

1 

differ  time 

72 

15 

30 

2 

0 

0 

0 

1 

same  time 

74 

16 

31 

2 

0 

0 

0 

1 
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Appendix  R  -  Single  Mode  Optical  Fiber  (SM  Fiber) 

R.1  Device  Description: 

Single  mode  fiber  is  used  throughout  optieal  components.  It  is  a  cylindrical  optical 
waveguide  made  from  a  low-loss  material,  such  as  silica  glass.  It  has  a  core  which  guides  the 
light  and  an  outer  cladding  that  reflects  the  internal  light  back  into  the  core,  bouncing  the  light 
down  the  fiber.  This  cladding  helps  to  reflect  outside  light  to  keep  in  from  entering  the  core.  This 
structure  allows  for  low  loss  over  long  distances  (Saleh  &  Teich,  1991).  The  single -mode  of  the 
fiber  comes  from  using  a  small  core  diameter  (-'10pm  @  1550nm)  and  small  numerical  aperture 
with  the  fundamental  mode  having  a  bell-shaped  spatial  distribution  similar  (Saleh  &  Teich, 
1991;  ThorLabs,  2013).  See  Figure  1  for  an  example  of  a  single  fiber  cable. 

SINGLE  FIBER  CABLE 


Figure  168.  View  of  a  single  fiber  cable  (Newport,  2013). 

The  SM  fiber  is  a  bidirectional  optical  component  with  two  optical  ports.  Light  entering 
the  primary  port  is  propagated  through  the  fiber,  suffering  both  a  slight  attenuation  from  the 
material  of  the  device  and  a  small  propagation  delay  dependent  on  the  temperature  of  the  fiber. 
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This  type  of  fiber  does  not  maintain  polarization  of  the  incoming  light,  so  there  will  be  a  random 
polarization  effect  on  the  light. 

The  internal  material  is  sensitive  to  the  power  of  the  optical  signals  that  are  propagated 
through  the  component.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold,  the  SM  fiber 
may  become  permanently  damaged  which  changes  its  propagation  characteristics.  Similarly,  the 
SM  fiber  is  sensitive  to  the  temperature  in  the  environment  in  which  it  operates.  If  the 
temperature  exceeds  defined  thresholds,  the  SM  fiber  may  become  temporarily  degraded  or 
permanently  damaged  which  changes  its  propagation  characteristics.  If  temporarily  degraded, 
the  device  may  recover  to  normal  operating  behavior  after  the  temperature  returns  to  a  “normal” 
operating  temperature. 

The  first  step  involved  with  the  modeling  the  SM  fiber  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
Optical  propagation  is  complex  process,  starting  with  the  characteristics  of  the  optical  fiber: 

•  Eoss 

•  Index  of  refraction 

•  Zero-dispersion  wavelengths 

•  Zero-dispersion  slopes 

•  Coefficient  of  thermal  expansion 

•  Chromatic  dispersion 

•  Polarization  mode  dispersion 

•  Rayleigh  backscatter 

Other  considerations  include: 

•  Temperature 

•  Vibration  and  disturbance 

•  Out-band  wavelengths 

•  Degraded  or  damaged  fiber 
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Raman  scattering 


These  characteristics  and  considerations  form  a  complex  web  of  dependencies  that  the  model 
must  include  if  light  is  to  be  properly  modeled.  See  Figure  2  for  the  dependency  web  from  the 
optical  SME. 


Modeling  light  as  discrete  event  requires  the  modeler  to  make  approximations  for  many 
of  its  characteristics,  starting  with  the  waveform.  The  optical  model  must  completely  describe 
any  type  of  optical  field  (pulsed,  continuous  wave,  arbitrary  polarization  states,  etc.)  and  be 
adaptable  for  future  changes.  The  optical  SME  created  an  optical  light  model  that  uses 
parameters  derived  from  the  Jones  vector  notation  of  light  and  uses  a  combination  of  three 
Gaussians  envelopes.  See  Eigure  1  for  the  Gaussian  approximation  of  a  laser  source. 
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Figure  170.  Approximation  of  an  ID  Quantique  ID300  Pulsed  laser  souree  (Optieal  SME). 


The  environment  surrounding  a  fiber  is  not  statie.  As  the  environment  and  external 
stresses  (temperature  change,  wind  effects  on  aerial  fibers,  vibrations  passed  through  the  ground 
to  buried  cables  etc.)  change,  the  birefringent  state  of  the  fiber  randomly  changes  over  time.  A 
random  variation  of  the  polarization  mode  coupling  along  the  length  of  the  fiber  is  induced  as 
well.  See  Figure  4  for  an  example  of  the  “polarization  walk.”  See  Appendix  2  for  the 
mathematical  model  for  this  variation. 
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The  importance  of  modeling  light  correctly  cannot  be  understated,  as  this  “optical 
packet”  is  the  base  of  the  entire  optical  model.  The  optical  SME  described  the  requirements  for 
the  optical  model  as  “all  elements  in  the  optical  physical  layer  must  be  capable  of  properly 
handling  any  optical  input  state,  react  properly  to  environmental  “inputs”,  accept  command  and 
control  messaging  (if  required),  and  must  be  as  physically  realistic  as  possible.” 

The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica 
software  program  that  modeled  the  SM  fiber,  developed  a  series  of  use  cases  that  exercised  the 
functionality  of  the  device  over  a  wide  variety  of  conditions,  verified  the  model  and  validated  the 
input  and  output  behavior  of  the  device  within  a  single  Mathematica  model  (worksheet).  The 
Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME  communicated  the 
behavior  of  the  SM  fiber  to  the  researcher.  See  Appendix  2  for  the  worksheet. 
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The  next  step  of  the  modeling  effort  was  to  develop  a  eoneeptual  model  of  the  SM  fiber 
using  the  DEVS  formalism.  The  bulk  of  the  doeument  following  this  seetion  is  dedieated  to  the 
detailed  development  of  the  DEVS  model  of  the  SM  fiber.  Onee  developed,  the  model  will  be 
simulated  using  the  MS4ME  simulator  using  the  same  uses  eases  defined  in  the  Mathematiea 
worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that  the  DEVS 
formal  model  matehes  the  behavior  of  the  Mathematiea  model  and  henee  the  real  eomponent. 

Onee  eompleted,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
ereated  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construetion  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 

0 

Figure  1 72.  Symbol  for  Singe  Mode  Eiber  in  the  QKD  system  architecture. 

R.2  Single  Mode  Fiber  Conceptual  Model 


Envin 

1 

r 

Optlrii 

OptOut 

w 

OptOuti 

SM  Fiber 

w 

Optln2 

Figure  172.  Single  Mode  fiber  (SM  fiber)  conceptual  model. 
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The  conceptual  model  for  a  SM  fiber  consists  of  two  optical  input  ports  {Optini,  OptIn2}, 
two  optical  output  ports  {OptOuti,  OptOuti},  and  one  environmental  input  port  {Evnin}.  The 
environmental  port  allows  external  sources  to  communicate  changes  in  the  operational 
environment  to  the  SM  fiber.  In  comparison  to  the  SM  fiber  symbol  used  in  the  QKD  simulation 
architecture  shown  in  Fig.  1,  a  single  bidirectional  optical  connection  is  decomposed  into  an 
optical  input  and  an  optical  output  in  the  conceptual  model.  This  is  necessary  to  properly 
represent  the  behavior  of  the  device  using  the  DEVS  formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  SM  fiber,  a  small  portion  of  the  signal 
will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  2  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  SM  fiber  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation.  External  environmental  messages 
sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the  SM  fiber  can 
determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In  either 
case,  a  function  determines  how  the  attenuation  changes  as  a  function  of  the  device  state  and 
current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation. 
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This  greatly  simplifies  the  modeling  of  all  of  the  other  optieal  eomponents  whieh  ean  treat 
multiple  optieal  signals  as  independent  entities. 

R.3  Mathematical  Model 

For  a  detailed  mathematieal  deseription  of  the  SM  fiber,  refer  to  Seetion  16.8  whieh  eontains 
the  Mathematica  worksheet  provided  by  the  optieal  physies  SME. 

R.4  English-Language  Rules 

In  this  seetion,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the  SM 
fiber. 

•  CurrentTemp  stores  the  eurrent  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  whieh  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  is  less  than  the  minimum 
power,  drop  the  pulse.  If  the  optical  power  exceeds  a  defined  damage  threshold,  set  the 
OverPower  flag. 

•  Place  the  optical  packet  into  the  queue. 

•  Remove  the  packet  from  the  queue;  calculate  the  attenuated  output  optical  signal  based 
upon  the  input  optical  signal,  the  OverPower  flag,  the  OverTemp  flag,  and  the  current 
environment  and  calculate  the  delay  through  the  fiber  based  on  its  length. 

•  Send  the  attenuated  and  delayed  output  signal  out  of  the  optical  output  port  number  that 
is  not  the  same  as  the  input  port  number. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 
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•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

R.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  SM  fiber  in  the  boxes  and 
the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled  with  the  type 
of  transition  (dext  -  external  or  dint  -  internal)  and  the  significant  actions  that  take  place  during  the 
transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value  of  the  time 
advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase  and  an  entry 
showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs.  Note  there  is 
a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the  SM  fiber  at 
the  same  time. 


state  =  {phase,  a,  store,  temperature,  overtemp,  overpower, 
interruptRespond,  queue. xl..xn}’ 


r 


dext  OPT/ 
OPTpwr  < 
minpwr 


ta  = 


dint/ 

queue 

=0 


ta  = 
00 


Passive 

A=0 

dext  ENV/ 
check 
overtemp 

ta=  00 


dext  OPT/ 
check 

overpower; 
insert  (xi,ta); 
get  queue 
(min) 


dext  OPT/ 
update 
queue; 
insert 
(xi,ta) 

ta 


dext  ENV/ 
update  queue 
ta;  get  queue 
(min) 


time 

delay 


Respond 
A  =  propagation 

/!\ 


ta= 

time 

delay 


dint/  queue  ! 
=0; get  queue 
(min);  set  ta 


ta  = 
time 
delay 


ta= 

time 

delay 


Figure  1 74.  SM  fiber  phase  transition  diagram. 
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R.  6  Event-Trace  Diagram 


This  section  shows  various  examples  of  packets  entering  the  SM  fiber.  The  tables  list  the 
states  the  SM  fiber  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  SM  fiber,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes. 

Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state.  Note 
for  optical  fiber,  the  time  for  the  respond  phase  is  variable  depending  on  the  length  of  the 
fiber.  In  the  following  cases,  the  time  of  propagation  through  the  fiber  is  set  to  5. 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Queue:  contents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 

R.  6. 1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  70.  Case  I  state  list. 

Notes: 

entry/  store  over  over  interrupt  queue  assume 


time 

state 

1-packet 

exit 

no  env 

phase 

no  ext 

sigma 

0  Ctrl 

(X/) 
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power 
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null 
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5 
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1  packet,  0  environmental  events,  0  external  events 


I 
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I  I 

Figure  1 75.  Case  I  sequence  diagram. 

R.  6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  7 1 .  Case  II  state  list. 

Notes: 

entry/  store  over  over  interrupt  queue  assume 


state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 
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1  packet,  0  environmental  events,  1  external  event  (with  1  packet)  at  e=2 


I 


Figure  1 76.  Case  II  sequence  diagram. 

R.6.3  CASE  III:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 

Table  72.  Case  III  state  list. 

Notes: 

entry/  store  over  over  interrupt  queue  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 
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Notes: 

entry/  store  over  over  interrupt  queue  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  respond  (x/,  tp)  tp=5 

1-packet  1  env  0  ext  0  Ctrl 
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entry 
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null 
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s4 

entry 
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inf 

xl 
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null 

1  packet,  1  environmental  event  at  e=3,  0  external  event 


Figure  1 78.  Case  IV  sequence  diagram. 

R.  7  Single  Mode  Fiber  Parallel  DEVS  Code 


Notes; 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 
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•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  fixed  SM  fiber  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  8ext,  8int,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp}  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  2  X  5  is  the  external  state  transition  function; 

Sint  =  S'  ^  S'  is  the  internal  state  transition  function; 

Scon  =  2  X  S  is  the  confluent  transition  function; 

=  S  ^  T*  is  the  output  function; 
to  =  S  ^  U  00  or  S  ^  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS  SM  fiber  {Xmi  Ym>  S,  Sexti  Sinti  Scorn 

where 

tp  ~  transmission  time  inside  the  attenuator 
temperature  =  current  temperature  of  the  attenuator 
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phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  optieal  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  current  optieal  packet 
peak.power  =  variable  the  holds  the  peak  power  of  the  current  optieal  paeket 
messagebag=  variable  that  stores  the  eurrent  x  input  value(s)  (p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optieal  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 
reflect  =  variable  that  stores  the  eurrent  refleeted  optical  packet 
reflect.port  =  variable  that  holds  the  current  refleetion  output  port 
reflect.power  =  variable  that  holds  the  eurrent  reflection  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
queue.current  =  variable  that  holds  the  eurrently  seleeted  queue  event 
store  =  variable  that  holds  values  of  the  eurrent  optical  packet 
timcLeftRespond  =  time  left  in  Respond  phase  for  the  eurrent  optical  packet 
e  =  elapsed  time  since  last  transition  oeeurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  seheduled  inputs 
queue  sizeO  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_refleeted()  =  method  returns  the  first  unrefieeted  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refiected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
insert_event_q()  =  method  that  inserts  the  eurrent  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  eurrent  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
ealePeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

ealeAttenDelayO  =  method  that  calculates  the  optieal  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

ealcStrongO  =  method  that  ealculates  the  optical  packet  high  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

caleWeakO  =  method  that  calculates  the  optieal  paeket  low  power  output  as  fcurrenlv, 
temperature,  overtemp,  peakpwr,  overpwr)) 

ealoForwardO  =  method  that  ealeulates  the  optieal  paeket  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 
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calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  /[store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  /{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReflectedQ  =  method  that  calculates  reflection  power  of  an  optical  packet 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 

q.Vmm  =  minimum  value  in  the  queue 

v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 
InPorts  =  {“Optini”,  “OptIn2”,  “Envin”}  with 

Xm  =  {(“Optini”,  Vopt),  (“OptIn2”,  Vopt),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 


OutPorts  =  {“OptOuti”,  “OptOut2”}  with 

Ym  =  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  Yoptouti)}  is  the  set  of  output  ports  and  values. 
phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower  interruptRespond,  queue)  = 
{{“passive”,  “reflect”,  “respond”}  x  ExRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  V) 

External  Transition  Function: 

dextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((p;,v,), . . . . 
iPn,Vn)))  = 

(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “passive”  and  p  E  {“Optlnf’,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 

if  calcAtten(cMrrent.v)  >  MIN_POWER 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
size=  queue_size() 
if  size  >  0 

current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  calcAttenDelay(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
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if  InPort  =  “Optini” 

outputPulse  =  calcAttenDelay(cMrren^.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
interruptRespond  =  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.xl.jcn) 
if  phase  =  “passive”  and  p  E  {“Optini”,  “OptIn2”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  eurrent.value.power  >  damaged.power 
overpower  =  “Y” 

if  ealeAtten(cMrren^.v)  >  MIN  POWER 
insert_event_q(cMrrenO 
remove_event_m(cMrre«^) 
size=  queue_size() 
if  size  <  0 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  E  {“Optini”,  “OptIn2”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  eurrent.value.power  >  damaged.power 
overpower  =  “Y” 

if  ealeAtten(cMrrent.v)  >  MIN  POWER 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time,  delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 
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{phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x  \  ..xn) 
otherwise; 


Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time_delay  =  eurrent.time. delay 
if  InPort  =  “Optlm” 

outputPulse  =  ealeAttenDelay(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOut2” 
if  InPort  =  “OptIn2” 

outputPulse  =  calcAttenDelay(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
outputPort  =  “OptOuti” 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  dexi§int{s),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 
(output.port,  output.pulse) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  =  cr; 
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R.8  Mathematical  Model 


Pulse  propagation  considerations  for  the  Fiber  Module  within  the 
QKD  OMNeH'*'  simulation  environment 

Physics 

c  :■  2.99792458  •  10*  (•spMd  of  m/s*) 

Pulse  CbaractCTistics  (c.g.) 

Xo  :■  1550*10'*  (*c«ntr«l  wavolongth  ia  aatars*) 

Aro  :■  400  •  10'*^  (*nniM  of  Gauaaian  pulso  shapo,  units  of  saconds*) 

Bo  :■  Bin(*input  powar  of  IsM  (i.a.  0  dBa)  •) 

Fiber  Characictistic  (modeled  upon  Cornii^  SMF  -  28) 

so  :■  50  *10*  (*50  ka  fibar  langth  at  original  taaparatura  Toa23C  •) 

TEC  :■  5 .  €  •  10'*  (•coafficiant  of  tharsal  axpansion,  1/”C  •) 

Loss  :•  0.17  (•loss  in  tha  fibar  •  1550nm,  dB/ka  •) 

n  :•  1.4662  (•fibar  indax  at  Toa23C,  1550na  •) 

nT  :■  1 .2  •  10'*  (*changa  in  fibar  indax.  1/"C,  froa  Tob23C  •) 

CD  :■  18  •  10'*^ (•chroaatic  disparsion,  units  of  saconds/ (ra^ka)  •) 

To  :■  23  (•  initial  anvironaantal  taaparatura  •) 

Tf  :■  50  (•  final  anvironaantal  tang>aratura  •) 

Propagation  Delay  Calculations 

Calculation  of  final  fiber  length 

&z  ■  zo  •  TEC  (Tf  -  To) 

0.756 

zf  ■  zo  •  az 
50000.8 

Calculation  of  effective  index 

An  • 

nT  (Tf  -  To)  (•calculatas  tha  changa  in  rafractiva  indax  dua  to  ta^iaratura  changa  •) 
0.000324 

nf  •  n  •  An  (•calculatas  tha  rafractiva  indax  •) 

1.46852 

Calculation  of  Propagation  Delay 

zf  •  nf 

PropOalay  ■  ■  (•  final  tiaa  is  in  saconds 

c 

0.000244927 

The  same  thing,  hut  in  long  fonn 

zo 

PropOalay  -  —  (1  *  TEC  (Tf  -  To) )  (n  •  nT  (Tf  -  To)  ) 
c 

0.000244927 


*) 


/.  Tf  -»  50  /  .  To  23 
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Change  in  propagaiioa  delay  through  the  fiber  due  to  temperature 
Eo  •  n 

At  •  PropOalay  -  - 

c 

5.77406  X  lO'* 

Chromatic  Dispersion  (pulse  broadening)  Calculations 

For  this  example  we  assume  the  time-power  profile  of  the  pulse  is  a  bandwidth-limited  "ideal*  Ciaussian.  Thus, 
the  timc-fitequency  bandwidth  product  is:  Aro*Avx>  =  0.441.  We  need  to  calculate  the  spread  in  wavelength  in  the 
pulse  to  calcuate  the  pulse  broadening 

Calculation  of  original  spectral  (frequency)  spread 
Avo  ■ 

0.441 /Aco  (•calculataa  tha  fcaqoaocy  FMHM  for  tha  original  pulao,  onita  of  Bartx*) 
1.1025  X 10* 

VO  ■  c  /  Jto  //  M 

(•calcolatas  cantax  fraqoancy  givan  cantral  wavalangth  Xo,  units  of  Hartz*) 

1.93414  X  10“ 

Avo  •  (Xo)  ^ 

Ala  - (vcalculatas  tba  spactral  mHM,  units  in  aatazs*) 

c 

8.8353  X  10*“ 

As  can  be  seen.  AA  is  very  small,  so  we  should  expect  little  pulse  broadening  due  to  chromatic  dispersion. 

Al  zf 

AcCS  ■  CO  •  - • - (v^raad  dua  to  chroaatic  disparsion,  units  of  saconds  •) 

10-*  1000 

7.95189  X 10*“ 


Acf  •  y  (Azo)* ♦  (AcCD)^  (*£lnAl  pulss  duration^  units  of  ssconds  •) 
4.00079  X  10*“ 


The  same  thing,  but  in  long  form 


Acf2  ■ 


(Aco)’ * 


0.441  /  Aco*  (Ao)^ 


4.00079  X 10*“ 


Loss  (final  power)  Calculations 


Here  we  calculate  the  power  of  the  pulse  after  h  has  passed  through  the  full  length  of  the  fiber, 
zf 

TotAttan  a  Loss  •  -  (•"Total  Attantuation"  in  units  of  dB  •) 

1000 

8.50013 


Ef  a  £o  •  V  10-*"****“^“  (,  output  fiald  *) 
0.375832  Ein 

Values  used  for  output  pulse 
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This  code  use&  lab-deliinrviled  lext  files  created  from  the  P1  and  P2  simjiated  random  walk  arrays  in  the 
Matlab  file  *RandomWaJk_v3*.  Note  that  the  two  arrays  must  have  the  same  length  of  samples  over 
the  same  time  period  (DeitaTI  =  DehaT2}. 

(*  these  Ar«  lOO  second  slmilstlons 
sampled  St  1  Bs  (lOOOOl  ssffiples  In  esch  array} 

(*  you  can  you  "AlphsKint .  tut"  and  "PlLtllini.  titt" 
which  are  only  1000  samples  each  •} 

Alpha  !=  IiQ»ort[  "C  ;  \Docuiunts  and  Set  ting  sSColin 

HcLaughllnXHy  Documents  VDr opbox.\QKD\Ha  th .  Hodels\Bandom 
ftalk  Hath  and  Vlsiiall£ations\Alpha .  txt~  j  ^Llsb"] 

Phi  :=  Import  [  "C :  \OocuiDents  and  Set  ting  s\Colln  Hclaughlin\Hy 
DocuBents\Dropbor.\QKD\Hath  .ModelB\Random 
Halt  Hath  and  Viaiialiiations\Phl.txt'',  "List"] 

{*  test  to  makes  sure  the  srrays  were  Imported  properly  *) 

Alpha[[l]] 

AlphA[[2]] 

Q 

-0.t)00£3a24S 

{*  generate  stokes  vectors 
si  :=  Cos  4  Alpha]  ^  Cos  [2-^  Phi] 
s2  :=  Slnl2*  Alpha]  *  Cob  [2*  Phi] 
s3  ;=  Sint2  *  Phlj 

(*  check  that  the  stokea  vectors  have 
been,  generated  and  are  the  correct  length 
Length] 
si] 

lOO  OOl 

(*  convert  the  stokea  vectors  into  triplets  according  to  time  sample  «) 
datapointa  :=  Transpose [Join [ {si ,  b2^  ^3}]] 

{ *  generate  the  aspects  o£  the  plot  * ) 

datapoin ts Sphere  =  Graphlcs3D [ ( (Qreen ,  PolntSlre [0 .001) ,  Point [ da tapoints  ] 

{Opacity [0.01) ,  sphere  [{0,  0,  0},  1]}}]; 
poincareSphere  =  Graphics3D  [(  (Black,.  PointSixe  [  0  .  D2  ] ,  Point[{0,  0,  1}], 

Point]  (Q,  0,  -1)  ] ,  Paint [{1,  0,  0}]  ^  Point  J{-1,  Q,  0}]  ,  Point ]{0,  1,  0>]  , 

Point]  (0,  -1,  0)]},  {Opacity]0.e) ,,  Sphere  ]{0,  0^  0},  1]}}]; 
eguators  =  {ParametricPlot3D  (Evaluate ] {Cos (t]  ^  Sin(t),  D}]  ,  {t,  0,  2  rr}, 

PlotStyle -r {Black,  Thin}] ,  Parametric Plot3D  {Evaluate) {Cos ] t]  ,  0,  Sin]t))), 

{t,  D,  2ji},  Plots  tyle ->  {Black,  Thin)],  ParametricFlotlD  ] 

Evaluate  ]  {0 ,  Cos  ]t]  ,  Sin  ]t] }  ]  ,  (t,  0 ,  2  tt)  ,  PlotStyle  (Black,  Thin}  ]  } ; 
psaxes  =  Graphics  3D  ]  {Line  (pa  ((-1,  0,  0),  {1,  0,  0}}],  Line  ]ps{{0,  -1,  0},  {0,  1,  Q}}], 
Line]pa  {{0,  0,  -1),  {0,  0,  1}}],  Text]  "SI",  {Ip,  0,  0}]  , 

Text]"s2-,  {0,  Ip,  0}]  ,  Text] "S3",  {0,  0,  Ip}] }  /  .  {ps  ^  l.lS,  Ip  1.3)) ; 
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(*  plot  thAt  bad  nutha: !  *) 

(*  nota  that  tha  plot  ia  dynaalc  - 
you  can  grab  and  drag  it  to  any  viawing  position  *) 
Show[dat^oint8Sphara,  poincaraSphara ,  aquators,  psaxas, 
Axas  -»  Falsa,  PlotRanga  ->1.2,  BasaStyla  ->  (Madium) , 

Boxad  -  Falsa,  ViawPoint  ->  {1.3,  2.4,  -1},  ImagaSiza  ->  600] 


s.; 


R.9  Component  Use  Case 


R.9.1  Respond  to  an  Optical  Packet  in  the  Single  Mode  Fiber  (SM  Fiber) 

Optical  packet  arrives  at  the  SM  fiber.  Place  the  optical  packet  into  the  optical  queue. 
Check  to  see  if  optical  packet  overpowers  the  SM  fiber.  Records  overpower  condition,  if 
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applicable.  Remove  the  optical  packet  from  the  queue  and  calculate  the  attenuated  optical  output 
signal  based  on  the  input  signal,  length  and  type  of  fiber,  and  the  current  component  state. 
Propagate  the  attenuated  optical  output  signal  out  of  the  component  optical  port  that  is  not  the 
same  as  the  input  port. 

•  Identified  Alternative  Uses  Cases 

o  React  to  an  environmental  message 

•  Assumptions 

o  Component  has  completed  initialization  sequence  at  least  once 
o  Reflections  are  not  affected  by  component  state 
o  Incoming  electrical  signals  are  not  affected  by  component  state 


Under  degraded 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


Reflections  are  not  configured  to  be  effected  by  state 
Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  1 79.  Component  states. 
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state  =  {phase,  a,  store,  temperature,  overtemp,  overpower, 
interruptRespond,  queue. xl..xn} 


dext  OPT/ 
OPTpwr  < 
minpwr 


dint/ 

queue 

=0 


dext  OPT/ 
update 
queue; 
insert 
(xi,ta) 


tas 

time 


Passive 
A  =  0 

dext  ENV/  /\ 
check 
overtemp 


dext  ENV/ 
update  queue 
ta;  get  queue 
(min) 


dext  OPT/ 
check 
overpower; 
insert  (xi,ta); 
get  queue 
(min) 


ta= 

time 

delay 


Respond 
Aspropagation 


dint/  queue  I 
=0;  get  queue 
(min);  set  ta 


ta= 

time 

delay 


ta  = 
time 
delay 


Figure  180.  SM  fiber  phase  transition  diagram. 

R.  9.2  Respond  to  Optical  Packet  End  Goals 


•  Optieal  paeket  entered  and  removed  from  queue  in  proper  sequenee 

•  Overpower  eondition  properly  reeognized  and  reeorded 

•  Optieal  paeket  attenuated  properly  to  the  limit  of  aeeuraey 

•  Optieal  paeket  propagated  out  the  eorreet  port  at  the  eorreet  time 

R.9.3  Respond  to  an  Environmental  Packet  in  the  Single  Mode  Eiber  (SM Eiber) 

Environmental  paeket  arrives  at  the  eomponent.  Cheek  to  see  if  environmental  paeket 
temperature  sets  the  eomponent  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level 
returns  eomponent  from  degraded  state  to  normal  state.  Reeords  ehange  in  eondition,  if 
applieable.  Change  eomponent  funetion  if  in  degraded  or  damaged  state. 


•  Assumptions 

o  None 

R.  9. 4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  paeket  reeeived  properly 

•  Overtemperature  eondition  properly  reeognized  and  reeorded 

•  Change  of  state  eompleted  and  reeorded  properly,  if  neeessary 

•  Change  eomponent  funetion  properly,  if  neeessary 
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R.10  SM  Fiber  Test  Cases 


Each  optical  component  was  tested  by  sending  inputs  into  the  eomponent,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  eheek  behavior  and  timing.  Each  component  had 
eaeh  of  its  input  ports  (optieal,  environmental  (env),  and/or  eontrol  (ctrl))  tested  singly,  then  in 
different  eombinations  of  ports  and  input  messages.  All  identified  errors  were  eorrected  and  the 
component  retested  until  it  funetioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  eomponent 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  proeessing. 
Control  messages  work  in  the  same  way,  but  foree  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  paekets  foree  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  eomponent  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  aeross  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reaeting  to  inputs  as  noted  at  the  top  of  each  table.  Eaeh  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  eolumn  lists  the  total  number  of  tests 
performed  on  a  eomponent;  suceessive  columns  list  the  number  of  those  tests  that  exercise  a 
partieular  port  (optieal,  etrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  ereated  by  the  optieal 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  eomparing  the  conceptual  models  to  the  qkdX  framework. 
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Table  5.  SM  Fiber  Test  Cases 


Inject  Ports 

Running  Totals 

Phase 

Case 

Optl 

Opt2 

Env 

Notes 

opt  # 

env  # 

Passive 

1 

1 

0 

0 

single 

1 

0 

2 

0 

1 

0 

single 

2 

0 

3 

0 

0 

1 

single 

2 

1 

4 

1 

1 

0 

same  time 

4 

1 

5 

1 

1 

0 

differ  time 

6 

1 

6 

1 

1 

1 

same  time 

8 

2 

7 

1 

1 

1 

differ  time 

10 

3 

8 

0 

1 

1 

same  time 

11 

4 

9 

0 

1 

1 

differ  time 

12 

5 

10 

1 

0 

1 

same  time 

13 

6 

11 

1 

0 

1 

differ  time 

14 

7 

20 

2 

0 

0 

same  time 

16 

7 

21 

0 

2 

0 

same  time 

18 

7 

22 

2 

2 

0 

same  time 

22 

7 

23 

2 

2 

0 

differ  time 

26 

7 

24 

2 

2 

1 

same  time 

30 

8 

25 

2 

2 

1 

differ  time 

34 

9 

26 

0 

2 

1 

same  time 

36 

10 

27 

0 

2 

1 

differ  time 

38 

11 

28 

2 

0 

1 

same  time 

40 

12 

29 

2 

0 

1 

differ  time 

42 

13 

totals 

21 

21 

13 

42 

Respond 

41 

2 

0 

0 

single 

44 

13 

42 

0 

2 

0 

single 

46 

13 

43 

1 

0 

1 

single 

47 

14 

44 

2 

1 

0 

same  time 

50 

14 

45 

2 

1 

0 

differ  time 

53 

14 

46 

2 

1 

1 

same  time 

56 

15 

47 

2 

1 

1 

differ  time 

59 

16 

48 

0 

2 

1 

same  time 

61 

17 

49 

0 

2 

1 

differ  time 

63 

18 

50 

2 

0 

1 

same  time 

65 

19 

51 

2 

0 

1 

differ  time 

67 

20 

60 

3 

0 

0 

same  time 

70 

20 

61 

0 

3 

0 

same  time 

73 

20 

62 

3 

2 

0 

same  time 

78 

20 

63 

3 

2 

0 

differ  time 

83 

20 

64 

3 

2 

1 

same  time 

88 

21 

65 

3 

2 

1 

differ  time 

93 

22 

66 

0 

3 

1 

same  time 

96 

23 

568 


totals 

67 

68 

69 

0 

3 

3 

3 

0 

0 

1 

1 

1 

differ  time 

same  time 

differ  time 

99 

102 

105 

24 

25 

26 

36 

27 

13 

63 

TCI 

1 

0 

2 

single 

106 

28 

TC2 

1 

0 

2 

single 

107 

30 

TC3 

1 

0 

2 

single 

108 

32 

TC4 

1 

0 

2 

single 

109 

34 

TC5 

1 

0 

2 

single 

110 

36 

TC6 

1 

0 

2 

single 

111 

38 

TC7 

1 

0 

2 

single 

112 

40 

totals 

7 

0 

14 

7 

Notes:  5  -  under  minimum  power  packet  sent  on  OPTl;  OPTl  &  OPT2  -  differ  time  -  Passive 

7  -  under  minimum  power  packet  sent  on  OPT2;  OPTl,  OPT2,  ENV  -  differ  time  - 
Passive 
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Appendix  S  -  Micro-Electromechanical  Systems  (MEMS)  Optical 

Switch 

S.l  Device  Description: 

The  optical  switch  is  used  to  route  light  between  one  input  port  and  two  or  more 
input/output  ports.  These  devices  usually  consist  of  an  electrically  movable  mirror  that  tilts  to 
direct  the  light  to  either  input/output  port.  The  device  is  non-latching,  meaning  that  electrical 
power  must  be  applied  for  the  device  to  maintain  a  connection  between  two  of  the  ports.  An 
optical  connection  is  maintained  to  one  output  port  when  the  electrical  power  is  “off’.  Typically, 
optical  switches  have  control  interfaces  that  allow  them  to  be  mounted  on  circuit  boards  or  have 
some  other  type  of  control  port  (DiConFiberOptics,  2013). 

The  micro-electromechanical  systems  (MEMS)  are  miniaturized  devices  integrating 
sensing  and  actuation  functions  to  control  systems  (Zangari,  2010),  powered  by  electrostatic 
actuators,  and  built  using  the  same  processes  used  in  fabricating  microelectronics.  Typically, 
optical  MEMS  switches  have  some  type  of  moving  mirror,  prism  or  holographic  grating  to 
deflect  the  light  beams.  Typical  switching  speeds  are  between  10ms  and  lOps  depending  on  the 
type  of  switching  system.  While  easily  fabricated,  the  major  limitation  of  these  devices  is  their 
slow  response  time,  but  they  offer  the  advantage  of  low  insertion  loss  and  loss  crosstalk  between 
channels  (Saleh  &  Teich,  1991).  See  Eigure  1  for  an  example  of  an  optical  switch. 
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OSW12-488-SM 


Figure  181.  Example  of  an  optical  switch  (ThorLabs,  2013). 

The  optical  switch  is  a  bidirectional  optical  component  with  three  optical  ports.  Optical 
signals  arriving  at  one  of  the  ports  is  directed  to  one  of  the  two  input/output  ports  and  propagated 
to  the  other  port  after  a  defined  propagation  delay.  The  switch  is  sensitive  to  the  power  of  the 
optical  signals  that  are  propagated  through  the  component.  If  the  optical  power  of  a  pulse 
exceeds  a  defined  threshold,  the  optical  switch  may  become  permanently  damaged  which 
changes  its  attenuation  characteristics.  Similarly,  the  optical  switch  is  sensitive  to  the 
temperature  in  the  environment  in  which  it  operates.  If  the  temperature  exceeds  defined 
thresholds,  the  optical  switch  may  become  temporarily  degraded  or  permanently  damaged  which 
changes  its  attenuation  characteristics.  If  temporarily  degraded,  the  device  may  recover  to 
normal  operating  behavior  after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  the  modeling  the  optical  switch  is  to  collect  and  understand 
the  physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica  software 
program  that  modeled  the  optical  switch.  The  SME  developed  a  series  of  use  cases  that  exercised 
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the  functionality  of  the  device  over  a  wide  variety  of  conditions  and  verified  the  model  and 
validated  the  input  and  output  behavior  of  the  device  within  a  single  Mathematica  model 
(worksheet).  The  Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME 
communicated  the  behavior  of  the  optical  switch  to  the  researcher.  Additional  information  came 
from  product  data  sheets  from  commercial  vendors  and  standard  texts  from  the  optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  optical 
switch  using  the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated 
to  the  detailed  development  of  the  DEVS  model  of  the  optical  switch.  Once  developed,  the 
model  will  be  simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  in  the 
Mathematica  worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that 
the  DEVS  formal  model  matches  the  behavior  of  the  Mathematica  model  and  hence  the  real 
component. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 


1 


Figure  182.  Symbol  for  the  optical  switc 


2 

3 

h  in  the  QKD  system  architecture. 
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S.2  Optical  switch  Conceptual  Model 


Optln2 

r 

OptOut2 

Optlrii 

Switch 

OptOut3 

OptOuti 

OptlPs 

Envin 

Ctrlln 

i 

i 

CtrlOut 

Figure  183.  Optical  switch  conceptual  model. 

The  eoneeptual  model  for  an  optical  switch  consists  of  three  optieal  input  ports  {Optini, 
Optini,  Optins},  two  optical  output  ports  {OptOuti,  OptOut2,  OptOuts},  one  environmental  input 
port  {Evnin}  and  one  eleetrieal  eontroller  input  port  and  one  eleetrieal  eontroller  output  port 
{Ctrlln,  CtrlOut}.  The  environmental  port  allows  external  sourees  to  eommunicate  ehanges  in 
the  operational  environment  to  the  optical  switch.  The  eleetrieal  controller  ports  allow  for  eontrol 
inputs  to  the  controller  and  responses  from  the  optical  switch  to  the  higher  system  functions. 

In  comparison  to  the  optieal  switeh  symbol  used  in  the  QKD  simulation  arehiteeture 
shown  in  Figure  2,  a  single  bidirectional  optical  connection  is  decomposed  into  an  optieal  input 
and  an  optieal  output  in  the  eoneeptual  model.  The  eleetrieal  eontrol  port  is  not  shown  for  elarity 
in  Figure  2,  and  is  also  decomposed  in  the  model  into  an  input  port  and  an  output  port.  This  is 
neeessary  to  properly  represent  the  behavior  of  the  deviee  using  the  DEVS  formalism. 

When  an  optical  signal  is  sent  to  the  input  of  the  optical  switch,  a  small  portion  of  the 
signal  will  be  instantaneously  refleeted  baek  to  the  signal  source.  Sinee  the  eoneeptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidireetional  output  input  and  a  discrete 
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unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  3  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  optical  switch  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation.  External  environmental  messages 
sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the  optical  switch 
can  determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In 
either  case,  a  function  determines  how  the  propagation  changes  as  a  function  of  the  device  state 
and  current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation.  This 
greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 

S.3  Mathematical  Model 

For  a  detailed  mathematical  description  of  the  optical  switch,  refer  to  Section  17.8  which 
contains  the  Mathematica  worksheet  provided  by  the  optical  physics  SME. 

S.4  English-Language  Rules 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
optical  switch. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  cleared. 
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•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  whieh  exeeed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optieal  signal  arrives: 

•  Determine  the  input  port  number. 

•  Calculate  the  optical  power  of  the  signal.  If  the  optical  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Plaee  the  optical  packet  into  the  queue 

•  Caleulate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same  port  number. 

•  Retrieve  the  input  optical  signal  from  the  queue  and  split  it  into  two  packets. 

•  Update  the  values  for  one  packet  as  a  ‘strong’  optieal  signal  based  on  the  eharacteristies 
of  the  switch,  the  original  values  of  the  input  optical  signal  and  the  eurrent  environment 
and  set  the  correct  output  port  (the  “normal  signal”). 

•  Update  the  values  for  the  other  paeket  as  a  ‘weak’  optical  signal  based  on  the 
charaeteristies  of  the  switch,  the  original  values  of  the  input  optieal  signal  and  the  current 
environment  and  set  the  correet  output  port  (the  “crosstalk”  signal). 

•  Update  the  values  of  the  input  optical  signal  based  on  the  eharaeteristies  of  the  switch,  the 
original  values  of  the  input  optieal  signal  and  the  current  environment. 

•  Send  the  changed  output  signal  out  of  the  optical  output  port  numbers  determined  by  the 
state  of  the  switch  and  the  erosstalk  characteristics. 

When  an  environmental  message  arrives: 

•  Update  the  CurrrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

When  a  control  message  arrives: 

•  Change  the  optical  path  to  the  correet  output  port  per  the  control  message. 

•  Respond  to  the  controller  with  an  acknowledgement  message. 

S.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  optical  switch  in  the  boxes 
and  the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled  with  the 
type  of  transition  {Aext  -  external  or  d/„^  -  internal)  and  the  significant  actions  that  take  place 
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during  the  transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value 
of  the  time  advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase 
and  an  entry  showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs. 
Note  there  is  a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the 
optical  switch  at  the  same  time. 


State  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  switchPosition, 
queue. xl..xn> 


dint/ 

queue=0 


ta=time 

delay 


dext 
ENV/ 
update 
queue  ta; 
set  ta 


00 


Passive 

A=0 


dext  OPT/  check  overpower;  insert  (xi,ta) 


ta=0 


dext 
J  ENV/ 
check 
overtemp 


dext 

CTRL/ 

Iswitchs 

neutral 


dint/  set 
switch 


tastime 

delay 


dext  CTRL/  set 
switch;  set  ta 


Update 

dext  CTRL/  switch=neutral;  ■  Switch 
_ clear  queue _ ^|^A=ctrl  msg 


K- 


Respond  . 
A=propagation  |^r“ 


dint/  interrrupt  =Y; 
^  needRespond=Y;  set  ta 
|\  ta=  time  delay 


/jWext  ENV/ 
check  over| 
temp 


*dint/ 
insert  (xi, 
— N  ^3) 


ta=0 


dext  OPT/  check 
{overpower;  insert  (xi,ta); 
set  sSigma 


Reflect  I 
iAsreflection  - 1 


7K 


dint/  needRespond=Y,  clear 
_ queue;  set  ta _ 


ta=time  delay 


ta=time 
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Figure  184.  optical  switch  phase  transition  diagram. 


S.6  Event-Trace  Diagram 


This  section  shows  various  examples  of  packets  entering  the  optical  switch.  The  tables 
list  the  states  the  optical  switch  proceeds  through  as  the  packets  are  processed.  Each  table  has  the 
state  number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  optical  switch,  the  over  temperature  flag  variable  and  the 
over  power  flag  variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the 
contents  of  the  store  state  variable  and  any  notes. 

Explanations  for  each  column: 
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•  Time:  elapsed  time  sinee  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Queue:  contents  of  the  queue  for  that  state 

•  Notes:  any  notes  for  that  state 

S,  6.1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  74.  Case  I  state  list. 
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1  packet,  0  environmental  events,  0  external  events,  0  control  events 


I  '  I 

Figure  185.  Case  I  sequence  diagram. 

S.6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  75.  Case  II  state  list. 
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Figure  187.  Case  III  sequence  diagram. 

S.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 

Table  77.  Case  IV  state  list. 


time 

state 

entry/ 

exit 

phase 

sigma 

store 

(xi) 

temp 

over 

temp 

over 

power 

interrupt 

respond 

need 

respond 

switch 

position 

queue 

(xi, 

tp) 

Notes: 

assume 
tp=  5 

1- 

packet 

1  env 

0  ext 

0  Ctrl 

0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

n 

n 

off 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

n 

n 

off 

(xl,5) 

0 

si 

entry 

reflect 

0 

null 

c 

n 

n 

n 

n 

off 

(xl,5) 

0 

si 

exit 

reflect 

5 

xl 

c 

n 

n 

n 

n 

off 

(xl,5) 

0 

s2 

entry 

respond 

5 

xl 

c 

n 

n 

n 

n 

off 

null 

ENV 

arrives 

e-3, 

overtemp 

the 

component 

3 

s2 

exit 

respond 

2 

xl 

c 

n 

n 

y 

n 

off 

null 

respond 

temp 

3 

s3 

entry 

respond 

2 

xl 

c 

y 

n 

y 

n 

off 

null 

5 

s3 

exit 

respond 

inf 

xl 

c2 

y 

n 

n 

n 

off 

null 

5 

s4 

entry 

passive 

inf 

xl 

c2 

y 

n 

n 

n 

off 

null 

1  packet,  1  environmental  event  at  e=3,  0  external  event,  0  control  events 


Passive 

— 1 — 

Reflect 

- 1 - 

Respond 

— 1 — 

Update  Switch 

- 1 - 

dext  optical  message 


I 


LJ 

u 

dint  optical  message 

1 

- ► 

1 

dext  env 

1 

message 

1 

1 

1 

◄ - 

1 

*  dint  l>pticdl  message 

J  : 

I 


Figure  188.  Case  IV  sequence  diagram. 
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S.6.5  CASE  V:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0,  Single  Control 
Packet  Arriving  at  Time 


Table  78.  Case  V state  list. 
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Figure  189.  Case  V  sequence  diagram. 

S.  7  Optical  switch  Parallel  DEVS  Code 


Notes: 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 
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•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  seales  involved  and  the  length  of  time  neeessary  for  temperature  fluetuations. 

•  Assume  that  only  one  eontrol  paeket  will  arrive  at  any  given  time,  due  to  the  small  time 
seales  involved  and  the  length  of  time  neeessary  for  optieal  path  ehanges. 

•  The  eomponent  will  always  refleet  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interrruptRespond”,  “needRespond”,  “switchPosition”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  optical  switch  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  dext,  Sint,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp)  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp}  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  2  X  ^  5  is  the  external  state  transition  function; 

Sint  =  S  S  is  the  internal  state  transition  function; 

Scon  =  2 X  X^j  Sis  the  confluent  transition  function; 

/I  =  S'  ^  T*  is  the  output  function; 

to  =  S  ^  U  00  or  S  ^  S  ,  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 
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DEVS  optical  switch  i^Mt  S^  Sextt  ^int^  ^coni  tu) 

where 

tp  =  transmission  time  inside  the  attenuator 
temperature  =  eurrent  temperature  of  the  attenuator 

phase  =  eontrol  state  that  keeps  traek  of  the  internal  phase  of  the  attenuator 
phase  =  {“passive”,  “refleet”,  “respond”,  “update  deteetor”} 

overtemp  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  deviee  meets  or  exeeeds  damaged  optieal  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
needRespond=  flag  variable  set  when  both  Refleet  and  UpdateDeteetor  respond  to  inputs 
switchPosition=  variable  that  holds  the  eurrent  switeh  position  {“on”,  “off’,  “neutral”} 
swtchSigma  =  variable  that  holds  the  time  advanee  for  the  Update  Switeh  phase 
attenpower  =  variable  the  holds  the  attenuated  power  of  the  eurrent  optieal  paeket 
peak.power  =  variable  the  holds  the  peak  power  of  the  eurrent  optieal  paeket 
messagebag=  variable  that  stores  the  eurrent  x  input  value(s)  {p,v) 

damaged.power  =  variable  that  holds  the  eomponent  damaged  optieal  power  level  parameter 

damage,  temp  =  variable  that  holds  the  eomponent  damaged  temperature  level  parameter 

current  =  variable  that  stores  the  queue  event  being  manipulated 

need.reflect=  variable  that  stores  queue  event  that  needs  refleeting 

reflect  =  variable  that  stores  the  eurrent  refleeted  optieal  paeket 

reflect.port  =  variable  that  holds  the  eurrent  refleetion  output  port 

reflect.power  =  variable  that  holds  the  eurrent  refleetion  power 

time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 

output.pulse=  variable  that  stores  the  output  optieal  paeket 

output.port  =  variable  that  holds  the  output  optieal  paeket  port 

size=  variable  that  holds  the  number  of  events  in  the  queue 

ctrlOutput  =  variable  that  stores  the  output  eontrol  message  response 

queue.current  =  variable  that  holds  the  eurrently  seleeted  queue  event 

store  =  variable  that  holds  values  of  the  eurrent  optieal  paeket 

timeLeftRespond  =  time  left  in  Respond  phase  for  the  eurrent  optieal  paeket 

e  =  elapsed  time  sinee  last  transition  oeeurred 

a  =  state  variable  that  holds  the  time  to  next  transition 

queue  =  input  eontainer  objeet  to  store  the  seheduled  inputs 

queue_size()  =  method  that  returns  number  of  entries  in  the  queue 

queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 

queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 

queue_need_refleeted()  =  method  returns  the  first  unrefieeted  queue  event 

empty  all  qO  =  method  that  empties  the  queue 

messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refieeted()  =  method  that  marks  the  eurrent  queue  event  as  being  refleeted 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
etrlMsgO  =  method  that  generates  a  response  message  to  reeeived  eontrol  messages 
outputMsgO  =  method  that  generates  the  response  message  to  reeeived  optieal  paekets 
insert  event  qO  =  method  that  inserts  the  eurrent  (x,,  time  delay,)  into  the  queue 
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remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x/,  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  /{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  j{current.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  j{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReflectedO  =  method  that  calculates  reflection  power  of  an  optical  packet 
changePolarizationO  =  method  that  changes  current  polarization  of  the  PM 
calcAttenPolarO  =  method  that  calculates  the  optical  output  as  fpurrent.v,  temperature, 
overtemp,  peakpwr,  overpwr,  currentPolarization) 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 
q.v  =  pointer  to  a  value  in  the  queue 
q.Vmm  =  minimum  value  in  the  queue 
v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 


InPorts  =  {“Optini”,  “OptIn2”,  “  Optins”,  “Envin”,  “Ctrlln”}  with 
Xm=  {(“Optlm”,  Vopd,  (“OptIn2”,  Vopt),  (“Optins”,  Vopd,  (“Envin”,  Venv),  (“Ctrlln”,  Vetri)}  is  the 
set  of  input  ports  and  values. 

OutPorts  =  {“OptOuti”,  “OptOut2”,  “OptOuts”,  “CtrlOut”}  with 
Ym=  {(“OptOuti”,  YoptOuti),  (“OptOut2”,  Yoptouti),  (“OptOuts”,  Yoptouts),  (“CtrlOut”,  Ycmout)}  is 
the  set  of  output  ports  and  values. 

phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interrupt  Respond,  needRespond, 
switchPosition,  queue)  =  {{“passive”,  “reflect”,  “respond”,  “update  polarization”}  x  i^x  Ex 
R  X  {“Y”,  “N”}  X  {“Y”,”N”}  X  {“Y”,”N”}  x  {“Y”,”N”}  x  {‘‘off’,  “on”,  “neutral”}  x  V) 

External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond  , 

switchPosition,  queue,  e,  ((/?,, v,),....  (pn,v„)))  = 


585 


(“reflect”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue.xl ..xn) 

if  phase  =  “passive”  and  p  E  {“Optini”,  “OptIn2”,  “Optins”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue. lirst(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflect”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue.xl.. xn) 

if  phase  =  “respond”  and  p  E  {“  Optini”,  “OptIn2”,  “Optins”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_need_reflected() 
reflect  =  (queue. current.p),  cadcRedQCiQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“reflect”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue.xl  ..xn) 

if  phase  =  “update  switch”  and  p  E  {“Optini”,  “OptIn2”,  “Optina”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrrent) 
queue.current  =  queue_lirst(^MeMe) 

reflect  =  (queue. current.p),  calcRQflQCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
switchSigma  =  switchSigma-  e 
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(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue.x\..xn) 

if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  switchPosition,  queue.x\..xn) 

if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time,  delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

(“update  switeh”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  switchPosition,  queue.x\..xn) 
if  phase  =  “update  switeh”  and  p  =  “Envin” 
update_delay(^MeMe) 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
switchSigma  =  switchSigma-  e 

(“update  switch”,  15x10^,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  switchPosition,  queue. x\..xn) 
if  phase  =  {“respond”,  “passive”}  and  switchPosition  =  3  and  p  =  “Ctrlln” 
if  switchPosition  =  “off’  and  store. value. voltage  =  “on” 
switchPosition  =  “neutral” 
ctrlOutput  =  ctrlMsg(5tore) 
emptyallqO 

ii switchPosition  =  “on”  and  store.value.voltage  =  “off’ 
switchPosition  =  “neutral” 

CtrlOutput  =  ctrlMsg(5tore) 
emptyallqO 

(“update  switch”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue.x\..xn) 

if  phase  =  “respond”  and  switchPosition  !=  3  and  p  =  “Ctrlln” 
update_delay(queue) 

CtrlOutput  =  ctrlMsg(5tore) 
interruptRespond=  “Y” 
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(“update  switch”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue.x\..xn) 

if  phase  =  “passive”  and  switchPosition  !=  3  and  p  =  “Ctrlln” 
ctrlOutput  =  ctrlMsg(5tore) 


(“update  switch”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  switchPosition,  queue.x\..xn) 

if  phase  =  “update  switch”  and  p  —  “Ctrlln” 
switchPosition  =  store. value. voltage 
switchSigma  =  switchSigma-  e 


(phase,  a  -  e, 
otherwise; 


00,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue.xl.jcn) 


Internal  Transition  Function: 


dintiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue)= 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue.xl.jcn)) 


if  phase  =  “reflect”  and  need.reflect  !=  null 
need.reflect  =  queue_need_reflected() 
current  =  need.reflect 

reflect  =  (current.p),  calcReflected(cMrrent.v)) 
mark_reflected(cMrre«t) 

(“update  switch”,  15x10^,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  switchPosition,  queue.x\..xn) 
if  phase  =  “reflect”  and  need.reflect  =  null  and  switchPosition  =3 
need.reflect  =  queue_need_reflected() 
empty_all_q() 

(“update  switch”,  0,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue.xl.jcn) 

if  phase  =  “reflect”  and  need.reflect  =  null  and  switchPosition  <  3 
need.reflect  =  queue_need_reflected() 

CtrlOutput  =  ctrlMsg(5tore) 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  switchPosition,  queue. xl..xn) 

if  phase  =  “reflect”  and  need.reflect  =  null 
need.reflect  =  queue_need_reflected() 
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if  interruptRespond  =  “N” 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optini”  and  switchPosition  =  “off’ 
newl  =  (“OptOut2”,  ca\cStvong(current.v,  temperature,  overtemp,  peakpwr,  overpwr) 
new2  =  (“OptOuts”,  calcWeak(cMrren^.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
if  InPort  =  “Optini”  and  switchPosition  =  “on” 
newl  =  (“OptOuts”,  calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
new2  =  (“0pt0ut2”,  calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
if  InPort  =  “0ptln2”  and  switchPosition  =  “off’ 
newl  =  (“OptOuti”,  calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
new2  =  (“OptOuts”,  calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
if  InPort  =  “Optins”  and  switchPosition  =  “on” 
newl  =  (“OptOuti”,  calcStrong(cMrrent.v,  temperature,  overtemp, peakpwr,  overpwr) 
new2  =  (“OptOuts”,  calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
timeLeftRespond  =  propagation  delay 
else 

time.delay  =  timeLeftRespond 

(“respond”,  time.delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  switchPosition,  queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time.delay  =  eurrent.time. delay 
if  InPort  =  “Optini”  and  switchPosition  =  “off’ 
newl  =  (“0pt0ut2”,  oaloStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
new2  =  (“OptOuts”,  oaloWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
if  InPort  =  “Optini”  and  switchPosition  =  “on” 
newl  =  (“OptOuts”,  oaloStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
new2  =  (“0pt0ut2”,  oaloWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
if  InPort  =  “0ptln2”  and  switchPosition  =  “off’ 
newl  =  (“OptOuti”,  calcStrong(cMrrent.v,  temperature,  overtemp, peakpwr,  overpwr) 
new2  =  (“OptOuts”,  caloWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
if  InPort  =  “Optins”  and  switchPosition  =  “on” 
newl  =  (“OptOuti”,  oaloStrong(cMrrent.v,  temperature,  overtemp, peakpwr,  overpwr) 
new2  =  (“OptOuts”,  oalcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue.xl.jcn) 

if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 


589 


(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  overpower,  interruptRespond, 

needRespond,  switchPosition,  queue.x\..xn) 
if  phase  =  “update  switch”  and  switchPosition  =3 
if  store.value.voltage=  “off’  and  switchPosition  =  3 
switchPosition  =  “off’ 

if  stor e.  value.  voltage=  “on”  and  switchPosition  =  3 
switchPosition  =  “on” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  overpower,  interruptRespond, 

needRespond,  switchPosition,  queue. x\..xn) 
if  phase  =  “update  switch”  and  needRespond  =  “N” 


(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

needRespond,  switchPosition,  queue. x\..xn) 
if  phase  =  “update  switch”  and  interruptRespond  =  “N”  and  needRespond  =  “Y” 
current  =  queue_min() 
time.delay  =  current.time. delay 
if  InPort  =  “Optini”  and  switchPosition  ~  “off’ 
newl  =  (“OptOut2”,  calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
new2  =  (“OptOuts”,  calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
if  InPort  =  “Optini”  and  switchPosition  =  “on” 
newl  =  (“OptOuts”,  calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
new2  =  (“OptOut2”,  calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
if  InPort  =  “OptIn2”  and  switchPosition  =  “off’ 
newl  =  (“OptOuti”,  calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
new2  =  (“OptOuts”,  calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
if  InPort  =  “OptIn3”  and  switchPosition  =  “on” 
newl  =  (“OptOuti”,  calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr) 
new2  =  (“OptOuts”,  calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond, 

switchPosition,  queue)  = 

{reflect.p,  reflect. v) 
if  phase  =  “reflecf  ’ 

(newl.p,  newl.v) 
if  phase  =  “respond” 

{new2.p,  new2.v) 
if  phase  =  “respond” 
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("CtrlOut",  ctrlOutput) 
if  phase  =  "update  switch" 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  interrupt  Respond,  needRespond, 

switchPosition,  queue)  =  cr; 
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S.8  Mathematical  Model 


Pulse  propagation  considerations  for  the  1x2  MEMS  Optical  Switch 
Module  within  the  QKD  OMNet<f  +  simulation  environment 

Optical  nbcr-bascd  MEMS  switches  arc  readily  available  (COTS)  hxmi  number  of  manufacturers.  This  module 
utilizes  common  parameters  for  1x2  swilclics  (though  other  switch  formats  arc  available),  and  is  of  the  non-latching 
type  (voltage  must  be  continuously  supplied  to  be  on  the  ”00"  position,  port  3  output).  Upon  removal  of  the  volt^. 
the  switch  will  drop  back  to  the  "ofF  position,  port  2  output  The  fiber  type  for  this  module  is  SMF-28  (single  mode 
Coming). 

The  operational  chaiactcnstics  arc  as  follows: 

-  light  input  to  port  I  will  exit  port  2  or  port  3 

-  light  input  to  port  2  will  exit  port  I  (or  be  attenuated  to  zero) 

-  light  input  to  port  3  will  exit  port  I  (or  be  attenuated  to  zero) 

The  only  significant  modificaOon  to  the  optical  nnessage  will  be  the  amplitude  (power). 

Pulse  Characteristics  (c.g.) 

These  parameters  are  used  in  the  joncs  representation  of  the  standard  coherent  pulse  optical  message  packet 

Pertinent  Pulse  Characteristics  for  the  Optical  Switch  Module 

Kinl  :a  Eo  (•  oloctzic  fiold  input  into  port  1  •) 

Kin2  :■  Eo  (•  oloctric  fiold  input  into  poet  2  •) 

Ein3  :■  Eo  (*  oloctzic  fiold  input  into  port  3  •) 

The  fallow  ing  parameter  values  are  examples  of  a  typical  optical  fiber-based  mems  switch  and  are  taken  from 
COTS  devices  offered  h>'  DiCon  Fiheroptics 

(littp://www.diconfiheroptics.coiii/prodHcts/?prod=0*44dkmenH=swt&snb=€).  Note  that  we  will  consder  [for 
naw|  the  crosstalk  amplitudes  to  he  zero  (infinite  attenuation). 

Optical  Specifications 

InaoctionLoos  :■  0.7  (•  maxi  mni  inaoction  loss,  uni  to  of  -dB  *) 

CzoaoTolk  :■  50  (•  wiximuoi  croontalk  (channol  2-*3,  3-*2) ,  units  of  -dB  •) 

Rotloss  :•  50  (•  ooxiortim  rotuen  loss, 

signal  cofloctod  by  on  input  boom,  units  of  -dB  •) 

ToogiU  :■  70  (•  mas  opocational  tonporaturo,  units  of  ‘C  •) 

Tompl.  :•  -5  (•  min  oporational  taoporaturo,  units  of  "C  •)  w 

MasPtre  :•  500  (*  maximnm  oporational  optical  poirar,  units  of  mH  •) 

OpticalftangoMin  :•  1530  (•  looor  bound  of  in-spoc  optical  wavolongth,  units  of  na  •) 

OpticalRangoMax  :•  1570  (•  uppor  bound  of  in-spoc  optical  wavolangth,  units  of  nm  •) 

ElecticakPhvsical  SnecMlcatiops 

latchingTypo  ;aNon  (•  dovico  will  rotum  to  "off*  stata  iq>on  romoral  of  voltago  •) 
SwitchingTisM  :■  15*10** 

(•  tisM  it  takas  for  dawico  to  switch  botwoon  "off"  to  "on*  statas,  units  of  soconds  *) 
Ihirability  :•  10*  (*  minimum  numbar  of  cyclos  bofora  dawico  failuro  •) 

ControlVoltago  ■  5  (•  TTL  woltago  for  switching,  units  of  Volts  *) 

Vcc  :■  12  (•  intamal  intagratad  circuit  powor  supply  woltago,  unit  of  Volts  •) 

VDamago  :■  15  (•  damago  throshold  for  intamal  intagratad  circuit,  units  of  Volts  •) 
BowarConsuaytion  :■  170  (•  maxinnim  olactrical  powor  consiaiption,  units  of  sM  *) 
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Operational/Attenuation  Calculations  for  1x2  Optical  Switch 

The  operation  of  this  device  will  have  three  'stales"; 

•  Slate  I;  "ofT*  •  optical  power  is  throughput  from  port  1  to  port  2  and  vice-versa. 

-  State  2;  "neutral"  -  optical  ouput  power  is  zero  from  all  ports.  This  will  last  for  "Switchii^Timc"  dmtion.  and  will 
occur  after  iccieving  a  TTL  on  (+5  V)  or  TTL  off  (0  V)  control  message 

-  Slate  3;  "on"  -  optical  power  is  throughput  from  port  I  to  port  3  and  vice-versa. 

Slate  I; 

Cout2(Binl_,  InaortionLoasJ  :•  Einl  *  V ip-r*-"*!-**-"'** 

(•  caso:  optical  Input  on  poet  1  •) 

Bout3(Einl_,  Inaactionl.oss_]  :■  Ki.nl  *0  (•  casa:  optical  input  on  port  1  •) 

Eootl  [Kin2_,  InsaxtionLoss_]  :  •  Ein2  • 

(•  casa:  optical  input  on  port  2  *) 

Bootl[Kin3_,  InaartionLoss_]  :■  Bin3  •  0  (•  casa:  optical  input  on  port  3  •) 

Stale  2; 

Raot2[Kinl_,  InaartionLoas_]  :■  Kinl  •  0  (•  casa:  optical  input  on  port  1  •) 

Boot3[Einl_,  InsartionLoas_]  :aEinl*0  (•  casa:  optical  input  on  port  1  •) 

Boutl  [Kin2_,  lnsartionLoss_]  :■  Ein2  *  0  (•  casa:  optical  input  on  port  2  •) 

Kootl[Kin3_,  lasartionLoas_]  :■  Kinl  •  0  (•  casa:  optical  input  on  port  3  *) 

Slate  3; 

Boot2[Einl_,  lnsartionLoss_]  :■  Kinl  •  0  (•  casa:  opitcal  input  on  port  1  •) 

Koot3[Kinl_«  Inaartionlpoas_]  :•  Kinl  •  "y  lO**"*"**^***"*^*® 

(•  casa:  optical  input  on  port  1  •) 

Kootl[Kin2_,  lnsartionLoss_]  :■  Kin2  •  0  (•  casa:  optical  input  on  port  2  •) 

Boutl [Kin3_,  InnartionLoss_]  :■ 

Ein3*  >/ (*  casa:  optical  input  on  port  3  •) 

If  we  wish  to  flag  the  optical  switch  to  iiKlude  undesired  return  (reflected)  messages,  the  following  operations 
would  hold  true. 

Boutl  (Kinl_,  Itatloss_]  :  ■  Kinl  • 

Eout2  [Kin2_,  ItatLoss_]  :  ■  Ein2  •  yj  iQ-®"**-"*/!® 

Boutl  [Kin3_,  ltatloss_]  :  ■  Einl  •  yj 

Polarizaion  Calculations  for  1x2  Optical  Switch 

For  a  the  1x2  optical  switch,  the  polariztion  chai^  can  be  related  to  that  of  a  similar  length  of  fiber,  in  this  case 
SMF-28.  This  will  be  incorporated  into  the  system  polarization  state  randomization  and  drift,  and  so  will  not  be 
included  in  this  module.  Using  the  stale  assignments  from  the  above  Operational/Attcnuation  calculations. 

Slate  I; 

Outpuitel2(InpoiPoll_]  :■  InpuCPoll 
OutpuiPDll(InpoiPol2_]  :■  InpuiPol2 

Slate  3; 

Ou^nitPol3(InpoiPoll_]  :■  InpuiPoll 
OutputPoll(InpotPol3_]  :■  InputPoll 
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CO'Hk  Wc'bcuLc  nulc^: 

bLlp:/MvrW.LH:niLLilL’t.L'(Kni'pnHjiicl_itklu4ifap7pnMjLK:bi_uML 
bU  p  w .  d  IC4X1 1 1  b«rv|)C  iL'^.c’uni/p  nxluc  bi/pnl_s(Ur  1  Be:  l»a.fTb  p 

bL!p://iA'upw.dicxjafibva‘V|iiiL'^_ex>ni/pff4xlLH:Li/'.’frod^)04^&:ii3c:iMJ^wtALMitrH) 
bL1p7/v^'wiA'.[lKfdiibL.>L'4mi^lKirl^fxlLH;L4:lin'.'pujlNLiiii>cT^JS  W1 Z- 1 3 1 0-isNI 
bUp7j/1unfiinu%-curWpc<HJucW!iwLlcbt!a/KL2/'i'j^Lid^n  Wli>4C^y!LMCKYZ\14.Ajud4t'4A.WQ 

S.9  Component  Use  Case 

S.9.1  Respond  to  an  Optical  Packet  in  the  Optical  Switch 

Optical  packet  arrives  at  the  optieal  switeh.  A  portion  of  optieal  paeket  refleets  baek 
down  ineoming  optieal  line.  Plaee  the  optieal  paeket  into  the  optieal  queue.  Cheek  to  see  if 
optieal  paeket  overpowers  the  optieal  switeh.  Reeords  overpower  eondition,  if  applieable. 
Remove  the  optieal  paeket  from  the  queue  and  ereate  transmitted  and  erosstalk  paekets. 
Caleulate  the  attenuated  optieal  output  signals  based  on  the  input  signal  and  the  eurrent 
eomponent  state.  Propagate  the  attenuated  optieal  output  signals  out  of  the  eomponent  optieal 
ports  based  on  the  input  port  and  switeh  position. 


•  Identified  Alternative  Uses  Cases 

o  Respond  to  a  eontrol  message 
o  Reaet  to  an  environmental  message 

•  Assumptions 

o  Component  has  eompleted  initialization  sequenee  at  least  onee 
o  Refieetions  are  not  affeeted  by  eomponent  state 
o  Ineoming  eleetrieal  signals  are  not  affeeted  by  eomponent  state 
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Initialization 

No  Optical  Output 


Normal  State 


*Reflections  are  not  configured  to  be  effected  by  state 
*Electricai  signals  are  not  configured  to  be  effected  by  state 


Figure  190.  Component  states. 


State  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  needRespond,  switchPosition, 
queue. xl..xn> 


dint/ 

queue=0 


ta=time 

delay 


% 


dext 
ENV/ 
update 
queue  ta; 
set  ta 


Passive 

A=0 


dext  OPT/  check  overpower;  insert  (xi,ta) 


ta=0 


ta- 

^  check 
overtemp 


dext 

CTRL/ 

switchs 

neutral 


dint/  set 
switch 


ta=time 

delay 


dext  CTRL/  set 
switch;  set  ta 


dext  CTRL/  switchsneutral; 
_ clear  queue _ ^  , 


Respond 

Aspropagation 

IK 


dint/  interrrupt  sY; 
needRespond  =  Y;  set  ta 


~  a=  time  delay 

< - 


^  Update 
Switch 
A=ctrl  msg 


/fttext  ENV/ 

check  over 
temp 


*dlnt/ 
insert  (xi, 
ta) 


ta=0 


■> 


Reflect 
k=reflection 


dext  OPT/  check 
>verpower;  insert  (xi,ta); 
set  sSigma 


dint/  needRespond=Y,  clear 
queue;  set  ta 


ta=time  delay 


ta=time 

dint/  get  queue(min);  set  ta  delay 


dint/ 
queue  1=0; 
get  queue 
(min);  set 
ta 


dext  OPT/  update  queue  ta;  insert  (xi,ta) 


ta=0 


ta=  time 
delay 

*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 
**  ta  =  0  or  15x10^9 


Figure  191.  optical  switch  phase  transition  diagram. 
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5.9.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  reflected  properly 

•  Optieal  paeket  entered  and  removed  from  queue  in  proper  sequenee 

•  Overpower  eondition  properly  reeognized  and  reeorded 

•  Optieal  paeket  attenuated  properly  to  the  limit  of  aeeuraey 

•  Optieal  paeket  propagated  out  the  eorreet  port  at  the  eorreet  time 

5.9.3  Respond  to  an  Environmental  Packet  in  the  Optical  Switch 

Environmental  paeket  arrives  at  the  eomponent.  Cheek  to  see  if  environmental  paeket 
temperature  sets  the  eomponent  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level 
returns  eomponent  from  degraded  state  to  normal  state.  Reeords  ehange  in  eondition,  if 
applieable.  Change  eomponent  function  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

S.  9.4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  paeket  reeeived  properly 

•  Overtemperature  eondition  properly  reeognized  and  reeorded 

•  Change  of  state  eompleted  and  recorded  properly,  if  neeessary 

•  Change  eomponent  funetion  properly,  if  neeessary 

S.9.5  Respond  to  a  Control  Message  in  the  Optical  Switch 

Control  Message  arrives  at  the  eomponent.  Component  deeodes  message  properly.  Reeords 
change  in  eondition  or  state,  if  applieable.  Change  component  function  if  in  degraded  or 
damaged  state  or  by  ehange  in  eomponent  eondition,  if  neeessary. 

•  Assumptions 

o  Component  has  completed  initialization  sequenee  at  least  onee 
S.  9. 6  Respond  to  Control  Message  End  Goals 

•  Control  message  reeeived  properly 

•  Change  of  eondition  or  state  eompleted  and  reeorded  properly,  if  neeessary 

•  Change  eomponent  function  properly,  if  neeessary 
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S.IO  MES  Switch  Test  Cases 


Each  optical  component  was  tested  by  sending  inputs  into  the  eomponent,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  eheek  behavior  and  timing.  Each  component  had 
eaeh  of  its  input  ports  (optieal,  environmental  (env),  and/or  eontrol  (ctrl))  tested  singly,  then  in 
different  eombinations  of  ports  and  input  messages.  All  identified  errors  were  eorrected  and  the 
component  retested  until  it  funetioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  proeessing. 
Control  messages  work  in  the  same  way,  but  foree  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  paekets  foree  an  immediate  response  to  the  change 
in  temperature,  possibly  changing  the  properties  of  the  eomponent  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  aeross  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reaeting  to  inputs  as  noted  at  the  top  of  each  table.  Eaeh  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  eolumn  lists  the  total  number  of  tests 
performed  on  a  eomponent;  suceessive  columns  list  the  number  of  those  tests  that  exercise  a 
partieular  port  (optieal,  etrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-speeific  tests.  These  math  tests  were  ereated  by  the  optieal 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  eomparing  the  conceptual  models  to  the  qkdX  framework. 
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Table  5.  MEMS  Switch  Test  Cases 


Phase 

Case 

Optl 

Inject  Ports 

Opt2  Opts 

Ctrl 

Env 

Notes 

Running  Totals 
opt  env  Ctrl 
#  #  # 

Passive 

1 

1 

0 

0 

0 

0 

single 

1 

0 

0 

2 

0 

1 

0 

0 

0 

single 

2 

0 

0 

3 

0 

0 

0 

1 

0 

single 

2 

0 

1 

4 

0 

0 

0 

0 

1 

single 

2 

1 

1 

5 

1 

1 

0 

0 

0 

same  time 

4 

1 

1 

6 

1 

0 

0 

1 

0 

same  time 

5 

1 

2 

7 

1 

1 

0 

0 

0 

differ  time 

7 

1 

2 

8 

1 

0 

0 

1 

0 

differ  time 

8 

1 

3 

9 

1 

1 

1 

1 

1 

same  time 

11 

2 

4 

10 

1 

0 

1 

2 

1 

differ  time 

13 

3 

6 

11 

0 

1 

0 

0 

1 

same  time 

14 

4 

6 

12 

0 

1 

0 

0 

1 

differ  time 

15 

5 

6 

13 

0 

0 

0 

1 

1 

same  time 

15 

6 

7 

14 

0 

0 

0 

1 

1 

differ  time 

15 

7 

8 

15 

1 

0 

0 

0 

1 

same  time 

16 

8 

8 

16 

1 

0 

0 

0 

1 

differ  time 

17 

9 

8 

20 

2 

0 

0 

0 

0 

same  time 

19 

9 

8 

21 

0 

2 

0 

0 

0 

same  time 

21 

9 

8 

22 

2 

1 

0 

0 

0 

same  time 

24 

9 

8 

23 

2 

0 

0 

1 

0 

same  time 

26 

9 

9 

24 

2 

0 

0 

0 

1 

same  time 

28 

10 

9 

25 

2 

0 

0 

1 

0 

differ  time 

30 

10 

10 

26 

2 

1 

0 

1 

1 

same  time 

33 

11 

11 

27 

2 

1 

0 

1 

1 

differ  time 

36 

12 

12 

28 

0 

2 

0 

0 

1 

same  time 

38 

13 

12 

29 

0 

2 

0 

0 

1 

differ  time 

40 

14 

12 

30 

0 

0 

0 

1 

1 

same  time 

40 

15 

13 

31 

0 

0 

0 

1 

1 

differ  time 

40 

16 

14 

32 

2 

0 

0 

0 

1 

same  time 

42 

17 

14 

33 

2 

0 

0 

0 

1 

differ  time 

44 

18 

14 

34 

0 

0 

1 

0 

0 

single 

45 

18 

14 

35 

1 

0 

1 

0 

0 

differ  time 

47 

18 

14 

36 

0 

1 

1 

0 

0 

differ  time 

49 

18 

14 

37 

0 

0 

1 

1 

0 

differ  time 

50 

18 

15 

38 

0 

0 

1 

0 

1 

differ  time 

51 

19 

15 

totals 

28 

16 

7 

15 

19 

51 

Respon 

d 

41 

2 

0 

0 

0 

0 

single 

53 

19 

15 

42 

1 

1 

0 

0 

0 

single 

55 

19 

15 

598 


43 

1 

0 

0 

1 

0 

single 

56 

19 

16 

44 

1 

0 

0 

0 

1 

single 

57 

20 

16 

45 

2 

1 

1 

0 

0 

same  time 

61 

20 

16 

46 

2 

0 

0 

1 

0 

same  time 

63 

20 

17 

47 

2 

0 

0 

0 

1 

differ  time 

65 

21 

17 

48 

2 

0 

0 

1 

0 

differ  time 

67 

21 

18 

49 

2 

1 

1 

1 

1 

same  time 

71 

22 

19 

50 

2 

0 

1 

2 

1 

differ  time 

74 

23 

21 

51 

1 

1 

0 

0 

1 

same  time 

76 

24 

21 

52 

1 

1 

0 

0 

1 

differ  time 

78 

25 

21 

60 

3 

0 

0 

0 

0 

same  time 

81 

25 

21 

61 

1 

2 

0 

0 

0 

same  time 

84 

25 

21 

62 

3 

1 

0 

0 

0 

same  time 

88 

25 

21 

63 

3 

0 

0 

1 

0 

same  time 

91 

25 

22 

64 

3 

0 

0 

0 

1 

same  time 

94 

26 

22 

65 

3 

0 

0 

1 

0 

differ  time 

97 

26 

23 

66 

3 

1 

0 

1 

1 

same  time 

101 

27 

24 

67 

3 

1 

0 

1 

1 

differ  time 

105 

28 

25 

68 

1 

2 

0 

0 

1 

same  time 

108 

29 

25 

69 

1 

2 

0 

0 

1 

differ  time 

111 

30 

25 

70 

1 

0 

1 

0 

0 

single 

113 

30 

25 

71 

1 

1 

1 

0 

0 

differ  time 

116 

30 

25 

72 

1 

0 

1 

1 

0 

differ  time 

118 

30 

26 

73 

1 

0 

1 

0 

1 

differ  time 

120 

31 

26 

74 

1 

0 

2 

0 

0 

differ  time 

123 

31 

26 

totals 

48 

15 

9 

11 

12 

72 

TCI 

1 

0 

0 

1 

2 

single 

124 

33 

27 

TC2 

1 

0 

0 

1 

2 

single 

125 

35 

28 

TC3 

1 

0 

0 

1 

2 

single 

126 

37 

29 

TC4 

1 

0 

0 

1 

2 

single 

127 

39 

30 

TC5 

1 

0 

0 

1 

2 

single 

128 

41 

31 

TC6 

1 

0 

0 

1 

2 

single 

129 

43 

32 

TC7 

1 

0 

0 

0 

2 

single 

130 

45 

32 

TC8 

1 

0 

0 

0 

2 

single 

131 

47 

32 

totals 

8 

0 

0 

6 

16 

Notes:  6-  Set  to  "on"  position,  port  1  to  port  3 

10  -  Set  to  "off"  position,  then  optl,  then  set  to  "on"  position,  then 
opt3,  then  env 

23  -  INIT  control  message  sent;  OPTl  &  Ctrl  -  same  time  -  Passive:  downstream  received 
packets  =  216 

25  -  INIT  control  message  sent;  OPTl  &  Ctrl  -  same  time  -  Passive:  downstream  received 
packets  =  216 

30  -  INIT  control  message  sent  -  Ctrl  &  ENV  -  same  time  -  Passive:  downstream  received 
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packets  =  216 

46-  Set  to  "off"  position,  port  1  to  port  2 

50  -  Send  optl  for  Respond  phase,  set  to  "off"  position,  then  optl,  then  set  to  "on"  position, 
then  opt3,  then  env 

63  -  INIT  control  message  sent  -  OPTl  &  Ctrl  -  same  time  -  Respond:  downstream  received 
packets  =  209 

67  -  INIT  control  message  sent  -  OPTl,  OPT2,  Ctrl  &  ENV  -  differ  time  -  Respond:  downstream 
received  packets  =  209 
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Appendix  T  -  Wave  Division  Multiplexer  (WDM) 


T.l  Device  Description: 

The  WDM  is  an  optical  device  used  to  combine  (or  split)  different  wavelengths  of  light 
into  one  stream.  Light  from  each  port  enters  through  a  collimation  lens,  combined  using  a 
dichroic  filter,  and  then  focused  on  a  collimation  lens  and  output  using  single  mode  fiber.  In  the 
opposite  direction  through  the  WDM,  combined  optical  signals  are  separated  into  different 
streams  and  sent  out  different  ports  (OZOptics,  2013).  Fiber-only  devices  exist  that  split  the 
beam  by  wavelength.  Signals  above  a  threshold  direct  to  one  port,  signals  below  go  to  the  other. 
A  WDM  can  be  made  from  housing  with  collimating  lenses  and  some  form  of  a  dichroic  mirror, 
a  mirror  made  from  thin  layers  of  different  transparent  optical  materials.  The  different  materials 
constructively  interfere  to  reflect  one  wavelength  and  transmit  the  other  (RPPhotonics,  2013). 
See  Figure  1  for  an  example  of  a  three  port  fiber-based  WDM. 


Figure  192.  View  of  a  three  port  WDM  (OZOptics,  2013). 

Although  there  are  WDMs  that  can  combine  many  different  wavelengths,  this  document 
will  cover  a  two-wavelength  device  that  utilizes  single-mode  input  and  output  fiber,  per  the 
discussion  with  the  SME. 

The  WDM  is  a  bidirectional  optical  component  with  three  optical  ports.  In  one  direction, 
optical  signals  arrive  at  two  of  the  input  ports,  slightly  attenuated  and  combined  for  output  on  the 
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third.  In  the  opposite  direction,  a  single  optical  input  is  split  into  two  steams,  each  stream  slightly 
attenuated,  and  output  to  individual  ports  depending  upon  wavelength. 

Although  designed  to  pass  wavelengths  within  a  specified  band  around  a  central 
wavelength  (pass  width)  for  each  port,  there  is  some  undesired  throughput  to  ports  1  and  2  when 
input  on  port  3.  These  are  highly  attenuated  signals,  with  the  attenuation  increasing  as  the 
undesired  frequency  moves  outside  of  the  pass  width  range,  much  like  a  bandpass  fdter.  Fiber- 
only  devices  do  not  have  this  undesired  throughput. 

In  the  model,  this  is  accounted  for  by  calculating  the  isolation  attenuation  for  any 
wavelength  outside  of  the  bandwidth,  increasing  the  attenuation  until  the  maximum  isolation 
value  is  reached  for  wavelengths  well  outside  the  pass  width.  A  check  is  made  on  the  power  of 
each  output  optical  packet  and  any  that  do  not  have  specified  minimum  amplitude  will  not  be 
emitted. 

Another  consideration  is  the  polarization  effect  of  the  dichroic  mirror  material  on  the 
optical  inputs.  If  the  WDM  has  single -mode  fiber  and  includes  a  dichroic  mirror,  the  wavelength 
that  reflects  on  the  mirror  will  have  a  7i/2  polarization  shift  along  with  any  shift  induced  by  the 
single -mode  fiber.  There  are  devices  that  use  polarization-maintaining  fiber,  but  as  noted  earlier, 
this  research  will  consider  only  single-mode  fiber  devices  (per  discussions  with  the  SME). 

The  internal  material  is  sensitive  to  the  power  of  the  optical  signals  that  are  propagated 
through  the  component.  If  the  optical  power  of  a  pulse  exceeds  a  defined  threshold,  the  WDM 
may  become  permanently  damaged  which  changes  its  propagation  characteristics.  Similarly,  the 
WDM  is  sensitive  to  the  temperature  in  the  environment  in  which  it  operates.  If  the  temperature 
exceeds  defined  thresholds,  the  WDM  may  become  temporarily  degraded  or  permanently 
damaged  which  changes  its  propagation  characteristics.  If  temporarily  degraded,  the  device  may 
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recover  to  normal  operating  behavior  after  the  temperature  returns  to  a  “normal”  operating 
temperature. 

The  first  step  involved  with  the  modeling  the  WDM  is  to  collect  and  understand  the 
physical,  behavioral,  and  performance  characteristics  of  the  component.  In  this  case,  this 
information  was  obtained  from  Subject  Matter  Expert  (SME)  with  expertise  in  optical  physics. 
The  SME  developed  a  detailed  mathematical  model  in  the  Wolfram  Mathematica  software 
program  that  modeled  the  WDM.  The  SME  developed  a  series  of  use  cases  that  exercised  the 
functionality  of  the  device  over  a  wide  variety  of  conditions  and  verified  the  model  and  validated 
the  input  and  output  behavior  of  the  device  within  a  single  Mathematica  model  (worksheet).  The 
Mathematica  worksheet  served  as  the  primary  means  by  which  the  SME  communicated  the 
behavior  of  the  WDM  to  the  researcher.  Additional  information  came  from  product  data  sheets 
from  commercial  vendors  and  standard  texts  from  the  optical  field. 

The  next  step  of  the  modeling  effort  was  to  develop  a  conceptual  model  of  the  WDM 
using  the  DEVS  formalism.  The  bulk  of  the  document  following  this  section  is  dedicated  to  the 
detailed  development  of  the  DEVS  model  of  the  WDM.  Once  developed,  the  model  will  be 
simulated  using  the  MS4ME  simulator  using  the  same  uses  cases  defined  in  the  Mathematica 
worksheet.  The  SME  will  then  review  the  MS4ME  simulation  output  to  verify  that  the  DEVS 
formal  model  matches  the  behavior  of  the  Mathematica  model  and  hence  the  real  component. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 
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1 


3 


2 

Figure  193.  Symbol  for  the  3-port  WDM  in  the  QKD  system  arehiteeture. 

T.2  WDM  Conceptual  Model 

I  Envin 


Optlrii 


OptOutg 


OptOuti 

0pt0ut2 

Figure  194.  WDM  eoneeptual  model. 


The  eoneeptual  model  for  a  WDM  eonsists  of  three  optieal  input  ports  {Optini,  OptIn2, 
OptIn3},  three  optieal  output  ports  {OptOuti,  OptOut2,  OptOuts},  and  one  environmental  input 
port  {Evnin}.  The  environmental  port  allows  external  sourees  to  eommunieate  ehanges  in  the 
operational  environment  to  the  WDM.  In  eomparison  to  the  WDM  symbol  used  in  the  QKD 
simulation  arehiteeture  shown  in  Figure  2,  a  single  bidireetional  optieal  eonneetion  is 
deeomposed  into  an  optieal  input  and  an  optieal  output  in  the  eoneeptual  model.  This  is 
neeessary  to  properly  represent  the  behavior  of  the  deviee  using  the  DEVS  formalism. 
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When  an  optical  signal  is  sent  to  the  input  of  the  WDM,  a  small  portion  of  the  signal  will 
be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model  decomposes 
each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  3  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  WDM  calculates  changes  to  any  packet  coming  through  an  optical  port  after  a  time 
equaling  the  propagation  delay  of  the  module.  The  packet  is  calculated  at  full  power  minus  some 
small  amount  to  account  for  attenuation  through  the  device  if  passing  through  to  the  correct  port 
or  heavily  attenuated  if  passing  to  an  incorrect  port  (for  example,  passing  from  port  one  to  port 
two).  The  model  handles  this  undesired  throughput  by  splitting  each  incoming  optical  packet  into 
a  ‘strong’  packet  (one  that  is  output  through  the  correct  port)  and  a  ‘weak’  packet  (one  that  is 
output  through  the  incorrect  port)  and  injecting  these  packets  into  the  queue.  Each  of  these 
entries  are  a  (port,  value)  pair,  just  as  any  other  entry  into  the  queue,  with  the  [port]  entry  equal 
to  the  output  port  and  the  [value]  equal  to  the  adjusted  values  of  the  incoming  packet. 
Additionally,  packets  output  on  port  two  rotate  nil  (i.e.  a  =  a  +  nil)  due  to  the  effects  of  the 
dichroic  mirror  inside  the  device  and  is  applied  by  the  by  the  ‘strong’  and  ‘weak’  functions. 

The  WDM  must  calculate  the  power  of  each  incoming  optical  signal  in  order  to 
determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation  is 
made  when  the  packet  first  enters  the  module.  In  the  case  of  optical  overpowering,  once 
overpowered  the  device  will  permanently  change  attenuation.  External  environmental  messages 
sent  to  the  device  convey  the  temperature  of  the  operational  environmental  so  the  WDM  can 
determine  if  it  is  degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  In  either 
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case,  a  function  determines  how  the  propagation  ehanges  as  a  function  of  the  device  state  and 
current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed  as 
independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only  model 
interferenee  at  the  Single  Photon  Deteetor  (SPD)  deviees  in  the  QKD  system  simulation.  This 
greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat  multiple 
optical  signals  as  independent  entities. 

T.3  Mathematical  Model 

For  a  detailed  mathematieal  deseription  of  the  WDM,  refer  to  Section  18.8  which  contains 
the  Mathematiea  worksheet  provided  by  the  optieal  physies  SME. 

T.4  English-Language  Rules 

In  this  seetion,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
WDM. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverPower  is  a  flag  whieh  indicates  if  the  device  is  permanently  damaged  due  to 
receiving  optical  signals  whose  optical  power  exceed  a  defined  power  threshold. 
Initially,  this  flag  is  eleared. 

•  OverTemp  is  a  flag  whieh  indicates  if  the  deviee  is  permanently  damaged  due  to  being 
exposed  to  temperatures  whieh  exeeed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  an  optical  signal  arrives: 

•  Determine  the  input  port  number. 

•  Immediately  calculate  the  reflected  power  of  the  signal  and  send  its  output  with  the  same 
port  number. 

•  Caleulate  the  optical  power  of  the  signal.  If  the  optieal  power  exceeds  a  defined  damage 
threshold,  set  the  OverPower  flag. 

•  Split  the  incoming  optical  packet  into  two  entries  in  the  queue. 
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•  Update  the  values  for  one  queue  entry  as  a  ‘strong’  optical  signal  based  on  the 
characteristics  of  the  WDM,  the  original  values  of  the  input  optical  signal  and  the  current 
environment  and  set  the  correct  output  port. 

•  Update  the  values  for  the  other  queue  entry  as  a  ‘weak’  optical  signal  based  on  the 
characteristics  of  the  WDM,  the  original  values  of  the  input  optical  signal  and  the  current 
environment  and  set  the  correct  output  port. 

•  After  the  propagation  time  has  elapsed,  send  the  output  signal  out  of  the  optical  output 
port. 

When  an  environmental  message  arrives: 

•  Update  the  Current! emp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 


T.5  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  WDM  in  the  boxes  and  the 
transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled  with  the  type  of 
transition  (dext  -  external  or  dint  -  internal)  and  the  significant  actions  that  take  place  during  the 
transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the  value  of  the  time 
advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the  phase  and  an  entry 
showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase  outputs.  Note  there  is 
a  self-loop  transition  from  reflect  to  reflect  if  multiple  optical  packets  arrive  at  the  WDM  at  the 
same  time. 
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state  =  {phase,  o,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  195.  WDM  phase  transition  diagram. 

T.6  Event-Trace  Diagram 

This  section  shows  various  examples  of  packets  entering  the  WDM.  The  tables  list  the 
states  the  WDM  proceeds  through  as  the  packets  are  processed.  Each  table  has  the  state  number, 
with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state  variable, 
current  temperature  of  the  WDM,  the  over  temperature  flag  variable  and  the  over  power  flag 
variable.  The  next  column  shows  the  contents  of  the  queue  at  that  state,  the  contents  of  the  store 
state  variable  and  any  notes. 

Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Queue:  contents  of  the  queue  for  that  state 
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•  Notes;  any  notes  for  that  state 

T.  6. 1  CASE  I:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0 

Table  79.  Case  I  state  list. 
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Figure  196.  Case  I  sequenee  diagram. 

T.6.2  CASE  II:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 

Table  80.  Case  II  state  list. 
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Figure  197.  Case  II  sequence  diagram. 

T.6.3  CASE  III:  Initial  Passive  with  Single  Optical  Packets  Arriving  at  Time  0  and  Time  2 
and  Multiple  Optical  Packets  Arriving  at  Time  3 

Table  81.  Case  III  state  list. 
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Figure  198.  Case  III  sequence  diagram. 

T.6.4  CASE  IV:  Initial  Passive  with  Single  Optical  Packet  Arriving  at  Time  0  and  Single 
Environmental  Packet  Arriving  at  Time  3 


Table  82.  Case  IV  state  list. 
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Figure  199.  Case  IV  sequence  diagram. 

T.  7  WDM  Parallel  DEVS  Code 


Notes; 

•  Peak  power  is  calculated  as  the  packet  outputs  rather  than  at  input  due  to  the  small  time  scale 
and  the  short  propagation  time  of  the  component. 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
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Definitions: 


State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“interruptRespond”,  queue} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
Peak  power  =  full  width,  half  maximum  power  calculation  of  the  pulse 

For  the  WDM  we  define: 

Parallel-DEVS  atomic  M=  {Xm,  Ym,  S,  Sext,  Sint,  Scon,  to) 

Where: 

Xm  =  {{p,v)  I  p  G  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp]  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  0  X  X\p  ^  5  is  the  external  state  transition  function; 

Sint  =  5*  ^  5*  is  the  internal  state  transition  function; 

Scon  =  2  X  X\p  ^  S'  is  the  confluent  transition  function; 

/I  =  S  — T*  is  the  output  function; 

to  =  S  ^  U  00  or  S  ^  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  to}^)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS]yi)M  {Xm^  Sextt  Sinh  Scorn 
where 

tp  =  transmission  time  inside  the  attenuator 

temperature  =  current  temperature  of  the  attenuator 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  attenuator 

phase  =  (“passive”,  “reflect”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
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attenpower  =  variable  the  holds  the  attenuated  power  of  the  eurrent  optieal  paeket 
peak.power  =  variable  the  holds  the  peak  power  of  the  eurrent  optieal  packet 
messagebag=  variable  that  stores  the  current  x  input  value(s)  (p,v) 

damaged.power  =  variable  that  holds  the  component  damaged  optical  power  level  parameter 
damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 
current  =  variable  that  stores  the  queue  event  being  manipulated 
need.reflect=  variable  that  stores  queue  event  that  needs  reflecting 
reflect  =  variable  that  stores  the  current  reflected  optical  packet 
reflect.port  =  variable  that  holds  the  current  reflection  output  port 
reflect.power  =  variable  that  holds  the  current  reflection  power 
time. delay  =  variable  that  stores  the  time  delay  in  the  queue  for  event  i 
output.pulse=  variable  that  stores  the  output  optical  packet 
output.port  =  variable  that  holds  the  output  optical  packet  port 
size=  variable  that  holds  the  number  of  events  in  the  queue 
newl=  variable  to  hold  1®‘  output  values 
new2  =  variable  to  hold  output  values 

queue.current  =  variable  that  holds  the  currently  selected  queue  event 
store  =  variable  that  holds  values  of  the  current  optical  packet 
timcLeftRespond  =  time  left  in  Respond  phase  for  the  current  optical  packet 
e  =  elapsed  time  since  last  transition  occurred 
a  =  state  variable  that  holds  the  time  to  next  transition 
queue  =  input  container  object  to  store  the  scheduled  inputs 
queue  sizeO  =  method  that  returns  number  of  entries  in  the  queue 
queue_min()  =  method  that  removes  the  queue  entry  with  the  smallest  time  delay 
queue_lirst()  =  method  that  returns  the  first  element  of  the  queue 
queue_need_reflected()  =  method  returns  the  first  unrefiected  queue  event 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
mark_refiected()  =  method  that  marks  the  current  queue  event  as  being  reflected 
update  delayO  =  method  that  updates  the  time  delay  of  entries  in  the  queue  by  e 
insert  event  qO  =  method  that  inserts  the  current  (x/,  time  delay,)  into  the  queue 
remove  event  qO  =  method  that  removes  the  current  (x„  0)  from  the  queue 
remove_event_m()  =  method  that  remove  the  current  (x„  time  delay,)  from  messagebag 
calcPeakO  =  function  that  calculates  full  width,  half  maximum  power  calculation  of  the  optical 
pulse 

calcAttenO  =  method  that  calculates  the  optical  packet  output  as:  f{store,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcStrongO  =  method  that  calculates  the  optical  packet  high  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcWeakO  =  method  that  calculates  the  optical  packet  low  power  output  as  fcurrent.v, 
temperature,  overtemp,  peakpwr,  overpwr)) 

calcForwardO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcReverseO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 

calcPolarO  =  method  that  calculates  the  optical  packet  output  as:  fstore,  temperature, 
overtemp,  peakpwr,  overpwr) 
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calcReflectedQ  =  method  that  calculates  reflection  power  of  an  optical  packet 

MIN  POWER  =  global  constant  that  is  the  minimum  acceptable  power  of  an  optical  packet 

q.v  =  pointer  to  a  value  in  the  queue 

q.Vmm  =  minimum  value  in  the  queue 

v.q  =  value  from  a  queue  entry 


Every  dext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Optini”,  “OptIn2”,  “Optinj”,  “Envin”}  with 
Xm  =  {(“Optini”,  Vopi),  (“OptIn2”,  Vopt),  (“OptIn3”,  Vopi),  (“Envin”,  Venv))  is  the  set  of  input 
ports  and  values. 

OutPorts  =  {“OptOuti”,  “OptOut2”,  “OptOuta”}  with 
Ym  =  {(“OptOuti”,  Yoptouti),  (“OptOut2”,  Yoptouti),  (“OptOuts”,  Yoptouts)}  is  the  set  of  output 
ports  and  values. 

phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower  interruptRespond,  queue)  = 
{{“passive”,  “reflect”,  “respond”}  x  ExRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  {“Y”,”N”}  x  V) 

External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue,  e,  ((p;,v,), . . . . 

iPmVn)))  = 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  queue.x\..xn) 
if  phase  =  “passive”  and  p  E  {“Optini”,  “OptIn2”,  “Optins”} 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
overpower  =  “Y” 
insert_event_q(cMrrent) 
remove_event_m(cMrre«t) 
queue.current  =  queue. flrst(^MeMe) 

reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond  =  “N” 

(“reflecf’,  0,  store,  temperature,  overtemp,  overpower,  queue.x\..xn) 
if  phase  =  “respond”  and  p  E  {“Optini”,  “OptIn2”,  “OptInS”} 
update_delay(^MeMe) 
for  messagebag  !=  null 
current  =  messagebag_first() 
if  current.value.power  >  damaged.power 
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overpower  =  “Y” 
insert_event_q(cMrrenO 
remove_event_m(cMrrenO 
queue. current  =  queue_need_reflected() 
reflect  =  (queue. current.p),  ca\cRQf[QCtQd(queue.current.v)) 
mark_reflected(^MeMe.  current) 
interruptRespond=  “Y” 
timeLeftRespond  =  timeLeftRespond  -  e 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.x\..xn) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

(“respond”,  time_delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “respond”  and  p  =  “Envin” 
update_delay(^MeMe) 
timeLeftRespond  =  time. delay-  e 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 
time. delay  =  timeLeftRespond 

(phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x  \  ..xn) 
otherwise; 

Internal  Transition  Function: 

di„t(phase,  a,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue)  = 

(“refleet”,  0,  temperature,  overtemp,  overpower,  interruptRespond,  queue. x\..xn)) 
if  phase  =  “refleet”  and  need.reflect  !=  null 
need.reflect  =  queue_need_refleeted() 
current  =  need.reflect 

reflect  =  (current.p),  ealeRefleeted(cMrrent.v)) 
mark_refleeted(cMrrent) 


(“respond”,  time. delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 

queue. x\..xn) 

if  phase  =  “refleet”  and  need.reflect  =  null 
need.reflect  =  queue_need_refleoted() 
if  interruptRespond  =  “N” 
current  =  queue_min() 
time. delay  =  current,  time. delay 


617 


if  current. p  =  “Optini”  /*  input  port  1  -  strong  3  weak  2  */ 

newl  =  (“OptOut3”,calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

new2  =  (“0pt0ut2”,calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

else 

if  current.p  =  “0ptln2”  /*  input  port  2  -  strong  3  weak  1  */ 

newl  =  (“OptOut3”,caleStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“OptOutl”,ealcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
else  /*  input  port  3  -  strong  1  strong  2*/ 

newl  =  (“OptOutl”,calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“OptOut2”,oalcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
timeLeftRespond  =  propagation  delay 
else 

time. delay  =  timeLeftRespond 

(“respond”,  time,  delay,  store,  temperature,  overtemp,  overpower,  interruptRespond, 
queue. x\..xn) 

if  phase  =  “respond”  and  size  >  0 
update_delay(^MeMe) 
size=  queue_size() 
current  =  queue_min() 
time. delay  =  current.time. delay 

if  current.p  =  “Optini”  /*  input  port  1  -  strong  3  weak  2  */ 

newl  =  (“OptOut3”,calcStrong(cMrrent.v,  temperature,  over  temp,  peakpwr,  overpwr)) 

newl  =  (“0pt0ut2”,caleWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 

else 

if  current.p  =  “0ptln2”  /*  input  port  2  -  strong  3  weak  1  */ 

newl  =  (“OptOut3”,calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“OptOutl”,calcWeak(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
else  /*  input  port  3  -  strong  1  strong  2*/ 

newl  =  (“OptOutl”,calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
newl  =  (“OptOut2”,calcStrong(cMrrent.v,  temperature,  overtemp,  peakpwr,  overpwr)) 
interruptRespond=  “N” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue.xl.jcn) 
if  phase  =  “respond”  and  size  =  0 
size=  queue_size() 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  dext{Sint{s),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower)  = 
{reflect.p,  reflect. v) 
if  phase  =  “reflect” 
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{newl.p,  newl.v) 
if  phase  =  “respond” 

{newl.p,  newl.v) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower)  =  cr; 
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T.8  Mathematical  Model 


Pulse  propagation  considerations  for  the  Dichroic  Mirror  (Wavelength 
Division  Multiplexer)  within  the  QKD  OMNet++  simulation 
environment 

The  dirchroic  miiror  (wavelength  division  multiplexer)  is  a  passive  device  which  combines,  in  a  low-loss  format,  two 
input  Mwelengths  into  a  single  fiber.  In  reverse,  the  device  functians  to  separate  two  co-propagating  wavelengths 
onto  separate  fibers.  They  are  frequently  used  for  add/drop  filicis,  erbium  doped  fiber  amplifier  (EOFA)  pumping, 
etc.,  in  the  telecommunications  industry.  The  devices  have  many  formats,  from  &ec-spacc  dichroic  tnirrois  (using 
collimating  dements  to  launch  from  and  focus  onto  the  fiber  ends),  to  in-line  fiber  devices.  Though  integrated  devices 
exist  which  can  combine  many  wavelengths,  we  will  here  consider  two  wavelei^ths.  namely  1310  and  1550  nm.  In 
both  applications  (Alice  and  Bob)  the  >AT)M  requires  single-nxxle  input  and  output  fiber  -  this  is  reflected  in  the  model 
below. 

The  primary  operational  characteristics  arc  as  follows: 

-  light  input  to  port  i  (at  uavdength  I )  will  exit  port  3 

-  light  input  to  port  2  (at  wavdcngtfa  2)  will  exit  port  3 

-  light  input  to  port  3  (at  wavdcngtfa  1 )  will  exit  port  I 

-  light  input  to  port  3  (at  wavdcngtfa  2)  will  exit  port  2 

The  only  signiiicani  modificalion  to  the  optical  message  will  be  the  amplitude  (power). 

Pulse  Characteristics  (cq{.) 

These  parameters  are  used  in  the  Jones  representation  of  the  standard  cobeteni  pulse  optical  message  packet. 

Pertinent  Pulse  Characterislics  for  the  Optical  Sw  itch  Module 
Clnl  :a  Eo  (*  oloctxic  fiold  input  into  port  1  •) 

MOl  :•  ul(*  optical  froquoncy  input  to  port  1,  units  of  rad/s  •) 

Kin2  :■  Eo  (•  alactric  fiald  input  into  port  2  •) 

tM>2  :■  u3  (•  optical  fraquancy  input  to  port  2,  units  of  rad/s  •) 

Bin3  :■  Eo  (•  alactric  fiald  input  into  port  3  •) 

im>3  :•  m3  (•  optical  fraquancy  input  to  port  3,  units  of  rad/s  •) 

The  follow  ing  parameter  values  are  examples  of  a  tv-pical  optical  fiber-based  WDM  and  are  taken  from  COTS 
"Miniature  Inline"  60dB  return-loss  devices  offered  bv  Oz  Optics 
(littp://ww'w.o2aptics.cam/.\LL.NEW_PDF/DTS0089qidO. 

Optical  Specifications 
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Insar^lonLosa  :■  0.7  (•  iMKiini  Insartion  loss,  unifca  of  -dB  •) 
laolafioo  :■  20 

(•  maaiiiai  powar  throughput  to  tha  Incorract  port  (froa  port  3) ,  unita  of  -dB  •) 

Ratlxiaa  :■  60  (•  aaaiafiim  ratum  loaa, 

aignal  raflactad  by  an  iiqnit  baam,  unita  of  -dB  •) 

TaagyH  :■  60  (•  maa  oparational  taaiparatura,  unita  of  ‘C  *) 

Taag>L  :•  -20  (•  ain  oparational  taaparatura,  unita  of  ^  •) 

MaaPwr  :■  200  (•  aaai  mna  oparational  optical  powar,  unita  of  tail  •) 

MavalangthPaaal  :■  1550*10'*  (•  wavalangth  paaaad  froa  port  1  •*  port  3, 
port  3  ^  port  1,  unita  of  a  •) 

HavalangthPaaa2  :■  1310*10'*  (*  wavalangth  paaaad  froa  port  2  •*  port  3, 
port  3  port  2,  unita  of  a  *) 

HavalongthFaaaHidth  :*  10*10'*  (*  width  of  paaa  widow 

(froa  apacification)  without  aignificant  loaa,  unita  of  •/-  m  *) 

Attenuation  Calculations  for  the  2  input  WDM 

Pint,  ae  must  calculate  Ibe  input  aavrknxths 

c  :■  2. 99792458  *  10*  (*  apaad  of  light,  unita  of  a/a  *) 

2  w  c 

A1  :■  -  (*  wavalangth  input  to  port  1,  unita  of  a  *) 

wol 

2  w  c 

X2  :■  -  (*  wavalangth  input  to  port  2,  unita  of  a  *) 

*k>2 

2  JT  c 

33  :■  -  (*  wavalangth  input  to  port  3,  unita  of  a  *) 

*k>3 

ln£nt_^ort_l^ 

Pseudocode: 

if  Al  s  Wa%elengtiiPassl+\%'avel«n0iiPass\\'idth  &&  Al  z  WavelenjttliPassl-WaselentttliPassWidtii 

Kout3(Binl_.  InaartionLoaa_]  :•  Kinl  * 

(*  caaa:  optical  input  on  port  1,  X  within  paaa  window  *) 

woot3(Mol_]  :•  Mol  (*  caaa:  optical  input  on  port  1,  Al  within  paaa  window  *) 

else 

Boot3  :■  0  (*  caaa:  optical  input  on  port  1,  Al  out  of  paaa  window,  aaaaaga  killad  *) 
(*  although  thia  ian't  fully  phycial,  until  wa  hava  an  appropriata  andal  for  out- 
of-band  wavalangtha  wa  will  kill  tha  aaaaaga  *) 

Pseudocode; 

if  A2  s  WavelengthPassA+Wavelenj^hPassW'idlh  &&  X2  z  >A'avelenKtliPass2-V\'a\elenstliPass\A  idth 

Eout3(Ein2_,  InaartionI,oaa_)  Ein2  *  V 

(*  caaa:  optical  input  on  port  2,  A2  within  paaa  window  *) 

woot3(«o2_]  :■  wo2  (*  caaa:  optical  input  on  port  2,  A  within  paaa  window  *) 

else 
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£out.3  :■  0  casK:  optical  i.n.put  on  port  2,  X2  out  of  pass  wiadow.,  massaga  killad  *} 

(*  although  this  isn't  fully  phycial ,  until  m  hava  as  appzopriata  nndal  fox  out- 
of-band  wavalangths  wa  vill  kill  tha  aassaga 

Input  Port  3: 

Pseud  PC  ode: 

if  .Us  \\'a>  cleB];lhPassl+^%'avcle'D}tthPa£s\Vidtli  &&  .U  2  %\'avcleiiftthPassl-\^'avelcn2tliPass\>'idth 

fioutl  (Ein.3_<  ln3«rtiDiiLoas_]  :  ■  Eici3  *  V 10-^'“^"^“' ** 

(*  casa :  optical  isput  on  port  3^  J13  vithin  port  1  pass  uisdow  *} 

«Kiutl[uo3_]  :•  uo3  casa:  optical  input  on  part  3,  JL3  within  part  1  pass  window 

C*  w«  may  wish  to  exaata  a  flag  to  allow  undaairad  throughput  *} 

Eout2(Ein3_,  InaaitionLoa s_,  laolotionj  :•  Ein3  *  \l 
caaa :  optical  input  on  port  3^ 

A3  within,  port  1  pass  window^  incorract  part  2  pass 
woutZ  [uo3_]  :•  uo3  casa:  optical  input  on  port  3, 

A3  within  port  1  pass  window*  incorract  port  2  pass  *) 

cbt  if  M  a^elensHiFaisl+l^'a^cIfaSthPaEsWidth  &&.  .13  £  avcl0D^hPaiE2‘\^'ave]cnKtliPa»\Milth 

Eout2  (Ein.3_,  Ina«i:tiimLoas_]  :  -  Ein3  *  V 

(*  caaa:  optical  input  on  port  A3  within  port  2  pass  window  *} 

wout2(uo3_]  :•  wo3  (*  casa:  optical  input  on  part  3*  A3  within  port  2  pass  window 

(*  wa  may  wish  to  craata  a  flag  to  allow  undasirad.  throughput  *)< 

Boutl  (Ein.3_.  lci»ticraLiMa_,  IsolationJ  :  •  E.in3  *  '-J 
C*  caaa:  optical  input  on  port  3^ 

A3  within  port  2  pass  window*  incorract  port  1  pass 
uoutl  [wo3_]  :m  003  (*  casa:  optical  input  on  port  3* 

A3  within  port  2  pass  window*  incorract  port  1  pass  -a-) 

else 

£outl  :•  casa:  optical  input  on  port  3* 

A  out  af  port  1  and  port  2  pass  windcw2^  loassaga  killad.  -t) 

Eaut2  :•  D  casa:  optical  input  on  part  3* 

A  out  of  port  1  and  port  2  pass  windnwZ ,  massaga  killad  «) 

although  this  isn't  fully  phycial*.  until  wa  hava  an  appxopriata  modal  for  out- 
of-band  wavaLangths  wa  will  kill  tha  massaga  *) 

Ifwc  wish  to  fla;g  the  2  Input  WDM  to  include  unde&ircd  return  (reflected)  mesBages,  the  following  opcratkHiA 
would  hold  true. 

Eoutl  (Eiiil_,  ft»tLosa_]  ;•  E.Lnl  *  V  iQ-x-ti"*'!" 

Bout2  [Eitt2_,  R»tLoss_]  :  ■  E.in2  * 

CDut3  [Ein.3_,  ft»tLoss_]  :  •  Ein3  *  V  TTi" 

Polarizaion  Consideralions  for  2  Input  WDM 

The  polarkztian  change  (br  an  opitcal  message  transiting  the  WDM  ean  be  related  to  that  of  a  similar  length  of  liber,  in 
ibis  ease  SMF-2S.  This  uill  be  incorporated  inlo  the  system  polarizatioa  slate  randomization  and  dritL  and.  so  will  not 
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be  included  in  this  module.  For  future  consideration:  if  the  do  ke  has  single-mode  fiber  pigtails  and  conlaias  dichroic 
mirror,  the  "refelected"  port  (typically  port  2)  will  experience  a  polanzaiion  shift  of  x/2  (i.e.  a  =  a+xfl)  in  addition  to 
the  polarization  shifts  in  the  fiber.  Des  ices  exist  (or  can  be  ordcrcdl  which  contain  PM  fiber,  in  which  case  polariza¬ 
tion  w  ill  be  maintained  through  the  device. 

CUTS  W  t.'lMile  ntms: 

hllp7/w vi«.iuuplK's.c«an/ALLNtW_PDK/DTS0U)i9.p«if  (•  cuotaim  ui-tuic  and  dichrinc  minur  type  WDM  *) 
faUp7/Hrww  .giwldfuLCuraiw  dm.aapx 

faUp7Ai  vi«.pacifu:iiilen;u.cum/Splincn_N_Cuuf)len>/l3 10-I550-W  DM.blni 

T.9  Component  Use  Case 

T.9.1  Respond  to  an  Optical  Packet  in  the  Wave  Division  Multiplexer  (WDM) 

Optical  packet  arrives  at  the  WDM.  A  portion  of  optieal  paeket  refleets  back  down 
incoming  optical  line.  Plaee  the  optieal  paeket  into  the  optieal  queue.  Cheek  to  see  if  optieal 
paeket  overpowers  the  WDM.  Reeords  overpower  eondition,  if  applicable.  Remove  the  optical 
packet  from  the  queue  and  ereate  transmitted  and  refleeted  paekets.  Caleulate  the  attenuated 
optical  output  signal  based  on  the  input  signal,  whether  transmitted  or  reflected,  and  the  current 
eomponent  state.  Propagate  the  attenuated  optieal  output  signals  out  of  the  eomponent  optieal 
ports  based  on  the  input  port  and  being  transmitted  or  reflected. 


•  Identified  Alternative  Uses  Cases 

o  Reaet  to  an  environmental  message 

•  Assumptions 

o  Component  has  eompleted  initialization  sequenee  at  least  onee 
o  Reflections  are  not  affeeted  by  eomponent  state 
o  Ineoming  eleetrieal  signals  are  not  affeeted  by  eomponent  state 
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Initialization 

No  Optical  Output 


Normal  State 


*Reflections  are  not  configured  to  be  effected  by  state 
*Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  200.  Component  states. 


state  =  {phase,  o,  store,  temperature,  overtemp,  overpower,  interruptRespond,  queue. xl..xn} 


ta=  time 
delay 


*  the  internal  transition  reflect  to  reflect  only  occurs  when  mulitple  optical  packets  arrive  at  the  same  time 

Figure  20 L  WDM  phase  transition  diagram. 

T.9.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  reflected  properly 

•  Optical  packet  entered  and  removed  from  queue  in  proper  sequence 
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•  Overpower  condition  properly  recognized  and  recorded 

•  Optical  packet  attenuated  properly  to  the  limit  of  accuracy 

•  Optical  packet  propagated  out  the  correct  port  at  the  correct  time 

T.9.3  Respond  to  an  Environmental  Packet  in  the  Wave  Division  Multiplexer  (WDM) 

Environmental  packet  arrives  at  the  component.  Check  to  see  if  environmental  packet 
temperature  sets  the  component  to  degraded  or  damaged  state.  Check  to  see  if  temperature  level 
returns  component  from  degraded  state  to  normal  state.  Records  change  in  condition,  if 
applicable.  Change  component  function  if  in  degraded  or  damaged  state. 

•  Assumptions 

o  None 

T.  9.4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 

•  Overtemperature  condition  properly  recognized  and  recorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

T.IO  WDM  Test  Cases 

Each  optical  component  was  tested  by  sending  inputs  into  the  component,  capturing  the 
output,  and  evaluating  the  output  line-by-line  to  check  behavior  and  timing.  Each  component  had 
each  of  its  input  ports  (optical,  environmental  (env),  and/or  control  (ctrl))  tested  singly,  then  in 
different  combinations  of  ports  and  input  messages.  All  identified  errors  were  corrected  and  the 
component  retested  until  it  functioned  properly  for  each  test  case. 

To  test  an  optical  port,  an  optical  message  is  injected  into  that  port  when  the  component 
is  in  Passive  or  Respond  phase.  This  tests  component  behavior  when  it  is  do  nothing  and 
awaiting  input  or  the  behavior  when  the  component  is  interrupted  during  message  processing. 
Control  messages  work  in  the  same  way,  but  force  the  component  to  begin  behavior  to  react  to 
the  contents  of  the  messages.  Environmental  packets  force  an  immediate  response  to  the  change 
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in  temperature,  possibly  changing  the  properties  of  the  component  if  it  is  damaged  or  degraded 
by  the  new  temperature. 

The  following  table  summarizes  these  tests  by  listing  the  component  on  the  left  and  the 
number  and  type  of  tests  across  the  top.  Each  component  is  in  either  the  Passive  or  Respond 
phase  when  reacting  to  inputs  as  noted  at  the  top  of  each  table.  Each  box  shows  the  number  of 
tests  exercising  the  particular  type  of  port.  The  first  column  lists  the  total  number  of  tests 
performed  on  a  component;  successive  columns  list  the  number  of  those  tests  that  exercise  a 
particular  port  (optical,  Ctrl,  or  env)  and  the  number  of  single  or  multi-port  tests,  with  the  final 
column  listing  the  number  of  math-specific  tests.  These  math  tests  were  created  by  the  optical 
SME  to  exercise  the  early  demonstration  QKD  simulation  and  added  in  the  MS4ME  code  for 
possible  future  work  in  comparing  the  conceptual  models  to  the  qkdX  framework. 

Table  5.  WDM  Test  Cases. 


Phase 

Case 

Inject  Ports 

Optl  Opt2  Opts 

Env 

Notes 

Running 

Totals 

opt  #  env  # 

Passive 

1 

1 

0 

0 

0 

single 

1 

0 

2 

0 

1 

0 

0 

single 

2 

0 

3 

0 

0 

1 

0 

single 

3 

0 

4 

0 

0 

0 

1 

single 

3 

1 

5 

1 

1 

1 

0 

same  time 

6 

1 

6 

1 

1 

1 

0 

differ  time 

9 

1 

7 

1 

1 

1 

1 

same  time 

12 

2 

8 

1 

1 

1 

1 

differ  time 

15 

3 

9 

0 

1 

0 

1 

same  time 

16 

4 

10 

0 

1 

0 

1 

differ  time 

17 

5 

11 

1 

0 

0 

1 

same  time 

18 

6 

12 

1 

0 

0 

1 

differ  time 

19 

7 

13 

0 

0 

1 

1 

same  time 

20 

8 

14 

0 

0 

1 

1 

differ  time 

21 

9 

20 

2 

0 

0 

0 

same  time 

23 

9 

21 

0 

2 

0 

0 

same  time 

25 

9 

22 

0 

0 

2 

0 

same  time 

27 

9 

23 

2 

2 

2 

0 

same  time 

33 

9 

24 

2 

2 

2 

0 

differ  time 

39 

9 
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25 

2 

2 

2 

1 

same  time 

45 

10 

26 

2 

2 

2 

1 

differ  time 

51 

11 

27 

0 

2 

0 

1 

same  time 

53 

12 

28 

0 

2 

0 

1 

differ  time 

55 

13 

29 

2 

0 

0 

1 

same  time 

57 

14 

30 

2 

0 

0 

1 

differ  time 

59 

15 

31 

0 

0 

2 

1 

same  time 

61 

16 

32 

0 

0 

2 

1 

differ  time 

63 

17 

totals 

21 

21 

21 

17 

63 

Respond 

41 

2 

0 

0 

0 

single 

65 

17 

42 

0 

2 

0 

0 

single 

67 

17 

43 

0 

0 

2 

0 

single 

69 

17 

44 

1 

0 

0 

1 

single 

70 

18 

45 

2 

1 

1 

0 

same  time 

74 

18 

46 

2 

1 

1 

0 

differ  time 

78 

18 

47 

2 

1 

1 

1 

same  time 

82 

19 

48 

2 

1 

1 

1 

differ  time 

86 

20 

49 

0 

2 

0 

1 

same  time 

88 

21 

50 

0 

2 

0 

1 

differ  time 

90 

22 

51 

2 

0 

0 

1 

same  time 

92 

23 

52 

2 

0 

0 

1 

differ  time 

94 

24 

53 

0 

0 

2 

1 

same  time 

96 

25 

54 

0 

0 

2 

1 

differ  time 

98 

26 

60 

3 

0 

0 

0 

same  time 

101 

26 

61 

0 

3 

0 

0 

same  time 

104 

26 

62 

0 

0 

3 

0 

same  time 

107 

26 

63 

3 

2 

2 

0 

same  time 

114 

26 

64 

3 

2 

2 

0 

differ  time 

121 

26 

65 

3 

2 

2 

1 

same  time 

128 

27 

66 

3 

2 

2 

1 

differ  time 

135 

28 

67 

0 

3 

0 

1 

same  time 

138 

29 

68 

0 

3 

0 

1 

differ  time 

141 

30 

69 

3 

0 

0 

1 

same  time 

144 

31 

70 

3 

0 

0 

1 

differ  time 

147 

32 

71 

0 

0 

3 

1 

same  time 

150 

33 

72 

0 

0 

3 

1 

differ  time 

153 

34 

totals 

36 

27 

27 

17 

90 

TCI 

1 

0 

0 

2 

single 

154 

36 

TC2 

1 

0 

0 

2 

single 

155 

38 

TC3 

1 

0 

0 

2 

single 

156 

40 

TC4 

1 

0 

0 

2 

single 

157 

42 

TC5 

1 

0 

0 

2 

single 

158 

44 

TC6 

1 

0 

0 

2 

single 

159 

46 
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TC7  [_ 

1 

0 

0 

2  single 

160 

48 

totals 

7 

0 

0 

14 

7 
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Appendix  U  -  Classical  Pulse  Generator  (CPG) 


U.l  Device  Description: 

The  ideal  eoneeptual  model  of  a  QKD  system  speeifies  polarization-eneoded  single 
photons  with  the  desired  bit  and  basis.  In  reality,  reliable  on-demand  single  photon  pulse 
generators  are  an  unrealized  teehnology.  Real-world  QKD  system  implementations  instead 
generate  a  laser  pulse  eontaining  millions  of  photons  and  strongly  attenuate  the  pulse  down  to 
statistieal  sub-photon  (quantum)  levels.  Within  the  Aliee  quantum  module,  the  CPG  subsystem 
generates  the  laser  pulses  and  shifts  them  into  a  known  polarization.  The  CPG  subsystem 
eontains  the  eomponents  shown  in  Fig.  1. 


Figure  202.  Classical  Pulse  Generator  (CPG)  in  the  QKD  system  architecture. 


The  CPG  subsystem  contains  a  controller,  a  laser,  an  isolator,  an  optical  polarizer,  an 
optical  bandpass  filter,  a  beamsplitter,  a  classical  detector,  electrical  interfaces,  and 
interconnecting  polarization-maintaining  (PM)  optical  fiber, 
propagation  delay. 

U.1.1  CPG  Controller 

The  controller  is  an  electrical  device  containing  digital  and  analog  circuits  responsible  for 
controlling  the  laser  and  monitoring  the  classical  detector.  It  has  a  bidirectional  electrical 
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interface  to  the  quantum  module  controller,  an  electrical  output  to  the  laser,  and  an  electrical 
input  from  the  classical  detector.  It  receives  commands  from  the  quantum  model  controller, 
sends  fire  commands  to  the  laser,  and  monitors  the  health  of  the  laser. 

U.1.2  Laser 

The  laser  is  an  electro-optical  device  which  contains  an  optical  oscillator  and  emits 
coherent  light  (Saleh  &  Teich,  1991).  It  has  an  electrical  input  to  receive  control  messages  and  an 
optical  output  to  emit  generated  pulses.  Within  the  simulation,  the  laser  creates  optical  pulses 
when  it  receives  a  “fire”  command  from  the  controller.  The  laser  generates  short-duration  laser 
pulses  (e.g.,  ImW  peak  intensity  with  a  500ps  duration)  containing  millions  of  photons 
(ThorLabs,  2013b).  The  output  of  the  laser  couples  to  the  input  of  the  isolator  via  PM  fiber. 

U.1.3  Isolator 

The  isolator  is  an  optical  device  with  two  bidirectional  optical  ports  that  passes  light  in 
the  forward  direction  while  significantly  attenuating  light  moving  in  the  opposite  direction 
(ThorLabs,  2013d).  Optical  signals  arriving  at  one  port  propagate  to  the  other  port  after  a  defined 
propagation  delay  with  the  attenuation  based  on  the  propagation  direction.  The  isolator  assures 
that  virtually  no  light  (e.g.,  reflections  or  light  from  external  sources)  enters  the  laser.  The  output 
of  the  isolator  is  coupled  to  the  input  of  the  polarizer  via  PM  fiber 

U.1.4  Polarizer 

The  polarizer  is  an  optical  device  with  two  bidirectional  optical  ports  allowing  light  of 
one  polarization  to  pass  while  highly  attenuating  light  orthogonal  to  the  passed  light  (ThorLabs, 
2013c).  Optical  signals  arriving  at  one  port  propagate  to  the  other  port  after  a  defined 
propagation  delay  and  polarized  depending  on  the  polarizer  orientation  with  respect  to  the 
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connected  fiber.  The  output  of  the  polarizer  is  coupled  to  the  input  of  the  optical  bandpass  filter 
via  PM  fiber. 

U.  1. 5  Bandpass  Filter 

The  bandpass  filter  is  an  optical  device  with  two  bidirectional  optical  ports  that  passes  the 
optical  energy  in  a  narrow  band  around  the  signal  wavelength,  ^s,  but  strongly  attenuates  other 
wavelengths  (ThorLabs,  2013a).  This  ensures  that  only  the  appropriate  signal  wavelength  leaves 
the  subsystem  while  preventing  other  sources  of  light  from  entering  the  laser.  Optical  signals 
arriving  at  one  port  propagate  to  the  other  port  after  a  defined  propagation  delay  and  are 
attenuated  based  on  the  wavelength  of  the  signal.  The  bandpass  filter  output  couples  to  port  1  of 
the  beamsplitter. 

U.  1. 6  Beamsplitter 

The  beamsplitter  is  an  optical  device  used  to  split  a  single  beam  of  light  into  two 
components.  It  can  also  be  used  to  combine  two  beams  of  light  into  one  stream  (OZOptics, 
2013).  Unlike  most  of  the  optical  devices,  it  has  four  bidirectional  optical  ports.  In  the  splitting 
configuration,  optical  signals  arriving  at  one  port  are  split  into  two  beams,  propagating  to  the 
appropriate  output  ports  after  a  defined  propagation  delay.  Common  splitting  ratios  are  50:50, 
90:10,  and  99:1,  but  devices  exist  in  almost  any  ratio.  Beams  can  also  be  split  according  to 
optical  wavelength  or  polarization.  The  beamsplitter  passes  99%  of  the  pulse  through  to  port  4, 
leaving  the  CPG  and  connecting  to  the  next  quantum  module  subsystem  as  shown  in  Fig.  9. 
Meanwhile,  port  3  passes  1%  of  the  pulse  on  to  the  classical  detector  via  PM  fiber. 

U.1.7  Classical  Detector 

The  classical  detector  is  an  opto-electrical  device  containing  an  optical  photodiode  and 
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support  electronics  to  generate  an  electrical  signal  proportional  to  the  power  contained  in  the 
optical  pulse  (ThorLabs,  2013e).  This  signal  connects  to  the  controller  which  stores  this 
information  and  checks  to  see  if  it  falls  below  a  predefined  threshold.  If  so,  the  controller  notifies 
the  quantum  module  controller  of  an  error  condition. 

U.  1. 8  Polarization-Maintaining  Optical  Fiber 

PM  fiber  is  a  specialty  fiber  that  intentionally  uses  the  strong  birefringence  in  two  modes. 
It  is  a  cylindrical  optical  waveguide  made  from  a  low-loss  material,  such  as  silica  glass,  and  has 
two  bidirectional  optical  ports.  Light  travels  down  one  of  the  modes  faster  than  down  the  other 
(fast  and  slow  axes).  If  the  input  light  is  polarized  and  oriented  along  either  mode,  it  maintains  its 
polarization  state  even  if  the  fiber  is  stressed  (OZOptics,  2014).  Typically,  PM  fiber  is  used  in 
components  that  cannot  have  drift  in  the  polarization  state  (such  as  fiber  interferometers  and 
some  fiber  lasers)  (RPPhotonics,  2013).  Optical  signals  arriving  at  one  port  propagate  to  the 
other  port  after  a  defined  propagation  delay. 

U.2  CPG  and  Controller  Behavior 

The  controller  and  individual  components  are  sensitive  to  the  temperature  in  the 
environment  in  which  they  operate.  If  the  temperature  exceeds  defined  thresholds,  the 
components  may  become  temporarily  degraded  or  permanently  damaged  which  changes  their 
characteristics.  If  temporarily  degraded,  the  devices  may  recover  to  normal  operating  behavior 
after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  modeling  the  controller  and  CPG  is  to  collect  and  understand 
the  physical,  behavioral,  and  performance  characteristics  of  the  atomic  components.  In  this  case, 
the  individual  components  were  constructed  earlier  and  the  controller  was  built  as  a  message 
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handler.  The  logie  for  the  eontroller  was  based  on  the  types  of  messages  neeessary  for  eontrol  of 
eomponents  inside  the  module. 

Onee  eompleted,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
ereated  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
eonstruetion  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 

U.3  CPG  Compound  Conceptual  Model 


CPG  module 


Envin 


Classical  Pulse  Generator 


Ctrllrii 


OptOut] 


CtrlOuti 


Optlrii 


Figure  203.  Classieal  Pulse  Generator  (CPG)  eompound  module  eoneeptual  model. 
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Ctrl  I  Pi 


CtrlOuti 


CtrlOut- 


Figure  204.  Classical  Pulse  Generator  (CPG)  controller  conceptual  model 


Table  83.  List  of  CPG  Controller  messages 


Input  Messages 

From 

Response 

CPGENV 

Quantum 

controller 

Set  the  internal  CPG  controller  temperature 

CPGRESET 

Quantum 

controller 

Resets  the  CPG  controller  and  clears  the  state 
variables 

CPGSTATUSREQUEST 

Quantum 

controller 

Sends  the  CPG  controller  status  and  stored 
magnitude  value 

CPGFIRELASER 

Quantum 

controller 

Issues  a  single  Fire  Easer  command  to  the  laser 

CDDETECTION 

Classical 

Detector 

Store  the  magnitude  from  the  message 

Output  Messages 

To 

Content 

CPGACK 

Quantum 

Controller 

Response  to  a  Reset  message 

CPG_STATUS 

Quantum 

Controller 

Response  to  a  Status  Request  message 

CPGEASERFIRE 

Easer 

Command  to  fire  the  laser  one  time 

The  conceptual  model  for  a  CPG  consists  of  one  optical  input  port  {Optini},  one  optical 
output  port  {OptOuti},  one  environmental  input  port  {Evnin},  one  control  input  port  {Ctrlln} 
and  one  control  output  port  {CtrlOut}.  The  environmental  port  allows  external  sources  to 
communicate  changes  in  the  operational  environment  to  the  CPG.  The  eleetrical  controller  ports 
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allow  for  control  inputs  to  the  controller  and  responses  from  the  CPG  to  the  higher  system 
functions. 

In  comparison  to  the  CPG  layout  used  in  the  QKD  simulation  architecture  shown  in  Fig. 
1,  a  single  bidirectional  optical  connection  is  decomposed  into  an  optical  input  and  an  optical 
output  in  the  conceptual  model.  This  is  necessary  to  properly  represent  the  behavior  of  the  device 
using  the  DEVS  formalism.  The  electrical  control  port  is  also  decomposed  in  the  model  into  an 
input  port  and  an  output  port. 

When  an  optical  signal  is  sent  to  the  input  of  the  CPG,  a  small  portion  of  the  signal  will 
be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model  decomposes 
each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  2  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  CPG  components  must  calculate  the  power  of  each  incoming  optical  signal  in  order 
to  determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This  calculation 
is  made  when  the  packet  first  enters  each  of  the  components  the  module.  In  the  case  of  optical 
overpowering,  once  overpowered  a  component  will  permanently  change  attenuation.  External 
environmental  messages  sent  to  the  CPG  are  directed  to  individual  components  convey  the 
temperature  of  the  operational  environmental  so  the  module  can  determine  if  it  is  degraded  (a 
temporary  condition)  or  damaged  (a  permanent  condition).  In  either  case,  a  function  determines 
how  the  attenuation  changes  as  a  function  of  the  device  state  and  current  temperature. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation. 
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This  greatly  simplifies  the  modeling  of  all  of  the  other  optieal  eomponents  whieh  ean  treat 
multiple  optieal  signals  as  independent  entities. 

U.4  English-Language  Rules  for  the  Controller 
In  this  seetion,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
eontroller. 

•  CurrentTemp  stores  the  eurrent  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverTemp  is  a  flag  whieh  indieates  if  the  deviee  is  permanently  damaged  due  to  being 
exposed  to  temperatures  whieh  exeeed  a  defined  temperature  threshold.  Initially,  this  flag 
is  eleared. 

When  a  eontrol  signal  arrives: 

•  Determine  the  arrival  port  of  the  signal. 

•  Evaluate  the  eontent  of  the  message 

•  Generate  a  response  message  to  the  ineoming  signal  (if  neeessary). 

•  Generate  a  forwarded  message  to  the  appropriate  deviee  (if  neeessary). 

•  Output  the  response  or  forwarded  message  out  the  appropriate  port. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  eurrent  temperature  eontained  in  the  environmental 
message. 

•  If  the  eurrent  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

U.5  DEVS  Phase  Transition  Diagram  (Controller) 

The  controller  phase  transition  diagram  in  Eig.  4  shows  the  phases  of  the  CFG  controller 
in  the  boxes  and  the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is 
labeled  with  the  type  of  transition  (dext  -  external  or  dint  -  internal)  and  the  significant  actions  that 
take  place  during  the  transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating 
the  value  of  the  time  advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of 
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the  phase  and  an  entry  showing  either  no  lambda  output  funetion  for  that  phase  or  what  the  phase 


outputs. 


state  =  {phase,  a,  store,  temperature,  overtemp, 
overpower,  lastCDPower} 


dext  CTRL/ 
class  detect 
msg 


dint/  go 
Passive 


ta  = 


oa 


Passive 

A=0 

dext  ENV/ 
check 
overtemp 

ta=  00 


Respond 


ta=0 


K 


A=ctrl  msg 


dext  CTRL/ 
laser  cmd; 
create  out 
msg 


Figure  205.  CPG  Controller  DEVS  phase  transition  diagram 

U.6  CPG  Controller  Event-Trace  Diagram 


This  seetion  shows  various  examples  of  paekets  entering  the  CPG  eontroller.  The  tables 
list  the  states  the  eomponent  proeeeds  through  as  the  paekets  are  proeessed.  Eaeh  table  has  the 
state  number,  with  eaeh  state  eonsisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  eurrent  temperature  of  the  eomponent,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  queue  eolumn  shows  the  eontents  of  the  queue  at  that  state,  the  eontents 
of  the  store  state  variable  and  any  notes.  Note  in  eontrast  to  most  other  eomponents,  the 
eontroller  is  very  simple  and  only  responds  to  ineoming  messages;  it  does  not  generate  any 
messages  on  its  own.  There  are  two  types  of  inputs:  eontrol  messages  and  environmental 


messages. 


Explanations  for  eaeh  eolumn: 
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•  Time:  elapsed  time  sinee  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  LastCDPower:  shows  the  power  of  the  last  classical  detection  message 

•  Notes:  any  notes  for  that  state 


U.6.1  CASE  I:  Initial  Passive  with  Single  Control  Packet  (Fire)  Arriving  at  Time  0 

Table  84.  Case  I  state  list. 


entry/  store  over  over  Notes: 

time  state  exit  phase  sigma  (x/)  temp  temp  power  lastCD  power  assume  tp=0 

1-packet  no  env  no  ext  1  Ctrl 


0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

null 

0 

si 

entry 

respond 

0 

null 

c 

n 

n 

null 

0 

si 

exit 

respond 

inf 

null 

c 

n 

n 

null 

0 

s2 

entry 

passive 

inf 

null 

c 

n 

n 

null 

U.  6.2  CASE  II:  Initial  Passive  with  Single  Environmental  Packet  Arriving  at  Time  0 

Table  85.  Case  II  state  list. 


time 

state 

1-packet 

entry/ 

exit 

1  env 

phase 

no  ext 

sigma 

0  Ctrl 

store 

(X/) 

temp 

over 

temp 

over 

power 

lastCD  power 

Notes: 

assume  tp=5 

0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

null 

0 

SI 

entry 

passive 

inf 

null 

c 

n 

n 

null 

U.7  Classical  Pulse  Generator  (CPG)  Controller  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 
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Definitions: 


State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”,  “lastCDPower”} 

Time  advance(state)  =  time  advance  of  the  current  state 

Time  delay  =  time  advance  stored  in  queue  for  event  i 

e  =  elapsed  time  since  last  transition  occurred 

“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
“lastCDPower”  =  variable  to  store  the  power  value  of  the  last  classical  detector  message 

For  the  CPG  controller  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  8 ext,  8i„t,  8con,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp]  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

8ext  =  2  X  XIj  ^  iS  is  the  external  state  transition  function; 

8int  =  S'  ^  S'  is  the  internal  state  transition  function; 

8con  =  2  X  Xh  ^  S  is  the  confluent  transition  function; 

/I  =  S  ^  T*  is  the  output  function; 

to  =  S^/CuooorS^i?+  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS CPGcontroller  {Xmi  Im,  S,  Sexti  8int^  8eom  -^9 


where 

tp  =  transmission  time  inside  the  component 
temperature  ~  current  temperature  of  the  component 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  component 
phase  =  {“passive”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
lastCDPower  =  variable  that  holds  the  power  value  of  the  last  classical  detector  message 
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interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 

messagebag=  variable  that  stores  the  eurrent  x  input  value(s)  {p,v) 

damage,  temp  =  variable  that  holds  the  eomponent  damaged  temperature  level  parameter 

current  =  variable  that  stores  the  queue  event  being  manipulated 

ctrlOutput  =  variable  that  stores  the  output  eontrol  message  response 

output.port  =  variable  that  holds  the  output  optical  packet  port 

store  =  variable  that  holds  values  of  the  current  input  values 

timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  event 

e  =  elapsed  time  since  last  transition  occurred 

a  =  state  variable  that  holds  the  time  to  next  transition 

messagebag_tirst()  =  method  that  returns  the  first  element  of  the  message  bag 
remove_event_m()  =  method  that  remove  the  current  (x,,  time  delay,)  from  messagebag 

Every  Sext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Ctrllni”,  “Ctrlln2”  “Envin”}  with 

Xm  =  {(“Ctrllni”,  Ertr/),  (“Ctrlln2”,  E^w),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 
OutPorts  =  {“CtrlOuti”,  “CtrlOut2”}  with 

Ym  =  {(“CtrlOuti”,  Yctriouti),  (“CtrlOut2”,  Y ctriOuti)}  is  the  set  of  output  ports  and  values. 
phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  =  {{“passive”, 
“respond”}  xVxRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  V} 

External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower,  e,  ((/7„v,), . . . .  (p«,v„)))  = 
(“respond”,  0,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “passive”  and  p  =  “Ctrllni” 

CtrlOutput  =  ctrlMsg(5tore) 
if  ctrlMsg.status  =  “init”  or  “get  status” 
outputPort  =  “CtrlOuti” 
if  CtrlMsg.status  =  “fire  laser” 
outputPort  =  “CtrlOut2” 

(“passive”,  0,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “passive”  and  p  =  “Ctrlln2” 
lastCDPower  =  messagebag.magnitude 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag. temperature 
if  temperature  >  damage,  temp 
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overtemp  =  “Y” 

{phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
otherwise; 

Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  = 
(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “respond” 

Confluence  Function: 


dconis,  ta{s),  x)  =  SextiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  = 
(outputPort,  ctrlOutput) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  =  cr; 

U.8  Classical  Pulse  Generator  (CPG)  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 

For  the  CPG  compound  module  we  define: 

Parallel-DEVS  compound N=  {X,  Y,  D,  {Md\AED},  EIC,  EOC,  IQ 

Where: 

X=  {{p,v)  I  p  G  IPorts,  V  G  Xp)  is  the  set  of  input  ports  and  values; 
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Y=  {(p,v)  I  p  G  OPorts,  V  G  Yp}  is  the  set  of  output  ports  and  values; 

D  =  set  of  component  names; 

Md  =  {Xd,  Yd,  S,  dext,  Sint,  Scon,  to)  is  a  DEVS  atomic  model; 

Xd  =  {ip,v)  I  p  G  IPorts,  vEXp}-, 

Yd  =  {{p,v)  I  p  G  OPorts,  vEYp]-, 

EICc  {((V  ipN),{d,ipd))\  ipN  G  IPorts,  dED,  ipd  E  IportSd}; 

EOC^  {{{d,opd),{N ,opn))\  opN  G  OPorts,  dED,  opd  G  OportSd}', 

IC  c  {((a,opa),{b,iph))\a,b  G  D,  opa  G  OportSa,  ipb  G  IportSb}', 

{{d,opd),{e,ipd))  G  /trimplies  d ^ e{no  feedback  loops); 

M=  an  atomic  instance  of  P-DEVS. 

N  =  a  compound  instance  of  P-DEVS. 

DEVScpg  =  (X,  Y,  D,  {Md  \  d  ED},  EIC,  EOC,  IQ 

InPorts  =  {“Ctrllm”,  “Ctrlln2”,  “Optlm”,  “Optlnj”,  “OptIn4”,  “Envin”} 

X=  {(“Ctrllm”,  v),  (“Ctrlln2”,  v),  (“Optlm”,  v),  (“Optlm”,  v),  (“OptIn4”,  v),  (“Envin”,  v)  \v  E  V} 

OutPorts  =  {“CtrlOuti”,  “CtrlOut2”,  “OptOuti”,  “OptOuts”,  “OptOut4”} 

Y=  {(“CtrlOuti”,  v),  (“CtrlOut2”,  v),  (“OptOuti”,  v),  (“OptOutj”,  v),  (“OptOut4”,  v)  \v  E  V} 

D  =  {controller,  laser,  isolator,  polarizer,  bandpass,  beamsplitter,  classicaldetector,  PMfiberi, 
PMfiber2,  PMfibers,  PMfiber4,  PMfibers,  PMfibere} 

Md  Mcontroller,  Mlaser,  Misdator,  Mpolarizer,  Mbandpass,  Mbeamsplitter,  Mclassicaldetector,  Mpfdfibelr,  Mpfdfiberl, 
MpMfiberi,  Mpfdfiberd’  Mpj^pflberS,  Mpj^jibcrb 

EIC  =  {{{N,  “CtrlIni”),(controller,  “Ctrllm”)),  ((V,  “EnvIn”),(controller,  “Envin”)),  ((V, 
“Envln”),(laser,  “Envin”)),  ((V,  “EnvIn”),(isolator,  “Envin”)),  ((V,  “EnvIn”),(polarizer, 
“Envin”)),  {{N,  “Envln”),(bandpass,  “Envin”)),  {{N,  “Envln”),(beamsplitter,  “Envin”)),  {{N, 
“EnvIn”),(classicaldetector,  “Envin”)),  ((V,  “EnvIn”),(PMfiberi,  “Envin”)),  ((V,  “Envin”), 
(PMfiber2,  “Envin”)),  {{N,  “EnvIn”),(PMfiber3,  “Envin”)),  {{N,  “EnvIn”),(PMfiber4,  “Envin”)), 
((V,  “EnvIn”),(PMfiber5,  “Envin”)),  ((V,  “EnvIn”),(PMfiber6,  “Envin”)),  ((V,  “Optini”), 
(PMfibers,  “OptIn2”))} 

EOC=  {((PMfibers,  “OptOut2”),(V,  “OptOuti”)),  ((controller,  “CtrlOuti”),(V,  “CtrlOuti”))} 

IC  =  {((controller,  “CtrlOut2”),  (laser,  “Ctrlln”)),  ((classicaldetector,  “CtrlOuti”),(controller, 
“Ctrllm”)),  ((laser,  “OptOuti ”),(PMfiberi,  “Optlm”)),  ((PMfiben,  “OptOuti ”),(laser,  “Optlm”)), 
((PMfiberi,  “OptOut2”),  (isolator,  “Optini”)),  ((isolator,  “OptOuti”),  (PMfiberi,  “Optlm”)), 
((isolator  “OptOut2”),  (PMfiber2,  “Optini”)),  ((PMfiber2,  “OptOuti”),  (isolator,  “Optlm”)), 
((PMfiber2,  “OptOut2”),  (polarizer,  “Optini”)),  ((polarizer,  “OptOuti”),  (PMfiber2,  “Optlm”)), 

((polarizer,  “OptOut2”),  (PMfibers,  “Optini”)),  ((PMfibers,  “OptOuti”),  (polarizer,  “Optlm”)), 

((PMfibers,  “OptOut2”),  (bandpass,  “Optlnf’)),  ((bandpass,  “OptOuti”),  (PMfibers,  “Optlm”)), 

((bandpass  “OptOut2”),  (PMfiber4,  “Optlnf’)),  ((PMfiber4,  “OptOuti”),  (bandpass,  “Optlm”)), 

((PMfiber4,  “OptOut2”),  (beamsplitter,  “Optini”)),  ((beamsplitter,  “OptOuti”),  (PMfiber4, 
“Optlm”)),  ((beamsplitter,  “OptOut4”),  (PMfibers,  “Optini”)),  ((PMfiberj,  “OptOuti”), 
(beamsplitter,  “Optlm”))^  ((beamsplitter,  “OptOut3”),(PMfiber6,  “Optlm”)),  ((PMfibere, 
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“OptOut2”), (beamsplitter,  “Optins”)),  ((PMfibere,  “OptOuti”), (classical detector,  “Optini”)), 
((classicaldetector,  “OptOuti”),(PMfiber6,  “Optlm”))} 

U.9  CPG  Controller  Use  Cases 


Initialization 

No  Optical  Output 


ormal  Stat 

pected  Optic 

L 

Output 

^ 

f 


Under  degraded 
temperature  or 
power  threshold 


Degraded  State 

Reduced  Optical 
Output 


Over  damaged 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


Damaged  State 

No  Optical  Output 


Over  damaged 
temperature  or 
power  threshold 


*Reflections  are  not  configured  to  be  effected  by  state 
^Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  206.  Component  states. 


state  =  {phase,  a,  store,  temperature,  overtemp, 
overpower,  currentAttenuation} 


Z' 


dext  CTRL/ 
class  detect 
msg 


dint/  go 
Passive 


ta  = 


oo 


Passive 

A=0 


dext  ENV/ 
check 
overtemp 


ta=  00 


Respond 
A=ctri  msg 


ta=0 


dext  CTRL/ 
create  out 
msg 


Figure  207.  Controller  phase  transition  diagram 
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U.  9. 1  Respond  to  a  Reset  Message 

Incoming  reset  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message  to 
the  module  eontroller.  Controller  elears  any  stored  variable  values  and  prepares  an 
aeknowledgement  message.  Response  message  is  sent  out  the  appropriate  port. 

•  Identified  Alternative  Uses  Cases 

o  Reaet  to  an  environmental  message 
o  Reaet  to  a  status  request  message 
o  Reaet  to  a  fire  laser  message 

o  Reaet  to  a  elassieal  detector  pulse  deteetion  message 

•  Assumptions 

o  Ineoming  eleetrieal  signals  are  not  affeeted  by  eomponent  state 
U.  9. 2  Respond  to  Reset  Message  En  d  Goals 

•  Message  properly  reeeived 

•  Controller  enters  Respond  phase  and  sets  storage  values  to  zero. 

•  Controller  forwards  Reset  Message  to  proper  eomponent(s)  as  neeessary 

•  Acknowledgement  message  ereated  and  sent  out  the  appropriate  port 

•  Controller  ends  in  Passive  phase 

U.9.3  Respond  to  an  Environmental  Packet 

Environmental  paeket  arrives  at  the  eontroller.  Cheek  to  see  if  environmental  paeket  temperature 
sets  the  eontroller  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level  returns 
eontroller  from  degraded  state  to  normal  state.  Reeords  ehange  in  eondition,  if  applieable. 
Change  controller  function  if  in  degraded  or  damaged  state,  if  neeessary. 

•  Assumptions 

o  None 

U.  9. 4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  paeket  reeeived  properly 

•  Overtemperature  eondition  properly  reeognized  and  reeorded 

•  Change  of  state  eompleted  and  reeorded  properly,  if  neeessary 

•  Change  eomponent  funetion  properly,  if  neeessary 
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U.  9. 5  Respond  to  a  Status  Request  Message 

Status  Request  message  arrives  at  the  module  from  the  quantum  eontroller.  Module  eontroller 
prepares  response  message.  Response  message  is  sent  out  the  appropriate  port. 

•  Assumptions 

o  Controller  has  eompleted  initialization  sequence  at  least  once 
U.  9. 6  Respond  to  Status  Request  End  Goals 

•  Control  message  received  properly 

•  Change  of  condition  or  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

U.  9. 7  Respond  to  a  Fire  Laser  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  laser  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
U. 9. 8  Respond  to  Fire  Laser  Message  End  Goals 

•  Fire  laser  message  received  properly 

•  Fire  message  recognized  and  passed  to  laser 

U.9.9  Respond  to  a  Classical  Detection  Message 

Incoming  detection  message  arrives  at  the  controller  from  the  classical  detector.  Store  the 
message  contents. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
U.9.10  Respond  to  Classical  Detection  Message  End  Goals 

•  CD  message  received  properly 

•  CD  message  values  stored  properly 
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U.IO  CPG  Module  Use  Cases 


U.10.1  Respond  to  an  Optical  Packet 

Optical  packet  arrives  at  the  module.  Pass  the  optical  packet  to  the  proper  internal  eomponent. 

•  Assumptions 

o  Reflections  are  not  affeeted  by  module  or  component  state 
U.IO. 2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  sent  to  proper  internal  component 
U.10.3  Respond  to  an  Environmental  Message 

Environmental  packet  arrives  at  the  module.  Environmental  message  is  passed  to  the  module 
controller  and  eaeh  component  in  the  module. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
U.10.4  Respond  to  Environmental  Message  End  Goals 

•  Environmental  packet  reeeived  properly  and  forwarded  to  eaeh  eomponent 
U.IO.  5  Respond  to  a  Control  Message 

Control  message  arrives  at  the  module.  Control  message  is  passed  to  the  module  eontroller. 

•  Assumptions 

o  Ineoming  eleetrieal  signals  are  not  affected  by  component  state 
U.10.6  Respond  to  Environmental  Message  End  Goals 

•  Control  message  received  properly  and  forwarded  to  the  module  controller 

U.ll  CPG  Test  Cases 

Eaeh  coupled  submodule  was  tested  by  sending  messages  to  the  submodule  and  using  the 
operational  graphics  of  the  MS4ME  simulator  to  traek  the  progress  of  the  message  through  the 
submodule.  The  primary  purpose  of  the  test  cases  was  testing  the  ability  of  the  eoupled 
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submodule  to  receive  messages,  pass  them  internally  to  the  submodule  controller  and  pass 
internal  output  to  external  ports.  The  controller  processed  these  input  messages  and  passed  an 
appropriate  message  to  the  controlled  opto-electrical  component.  The  type  of  control  message 
passed  to  each  coupled  submodule  depended  on  the  internal  components. 

•  CPG  submodule  -  control  message  fires  the  signal  laser 
These  test  cases  led  to  iterations  of  testing  and  correction.  Optical  messages  were  tracked 
through  the  internal  components  and  out  the  submodule  output.  Environmental  messages  were 
checked  to  ensure  they  replicated  to  each  internal  component.  All  the  errors  identified  in  the 
coupled  submodules  were  problems  with  coding  the  controllers,  as  the  atomic  components 
functioned  properly  during  coupling. 

Table  4.  Summary  of  Coupled  Submodule  Behavior  Testing. 


total 

tests 

optical 

ports 

Ctrl 

port 

env 

port 

Classical  Pulse  Generator 

4 

0 

3 

1 

Polarization  Modulator 

5 

1 

3 

1 

Decoy  State  Generator 

5 

1 

3 

1 

Classical  To  Quantum 

5 

1 

3 

1 

Optical  Security  Layer 

4 

1 

2 

1 

Timing  Pulse  Generator 

5 

1 

3 

1 

Optical  Power  Monitor 

5 

1 

3 

1 
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Appendix  V  -  Pulse  Modulator  (PM) 

V.l  Device  Description: 

The  pulse  modulator  creates  the  polarization  encoding  necessary  for  the  BB84  protocol. 
This  subsystem  reacts  to  commands  from  the  quantum  controller  to  polarize  the  optical  pulses 
generated  by  the  CFG  laser.  Some  QKD  systems  use  a  laser  for  each  type  of  polarization,  but 
this  architecture  uses  one  laser  and  component  to  change  each  packet  polarization.  The  PM 
subsystem  contains  the  components  shown  in  Fig.  1 . 


Figure  208.  Pulse  Modulator  (PM)  in  the  QKD  system  architecture. 

The  PM  subsystem  contains  a  controller,  a  polarization  modulator,  electrical  interfaces,  and 
interconnecting  single-mode  (SM)  and  polarization-controlling  optical  fiber.  We  briefly  discuss 
the  behavior  of  each  of  the  components  contained  within  the  module. 

V.  1. 1  PM  Controller 

The  controller  is  an  electrical  device  containing  digital  and  analog  circuits  responsible  for 
controlling  the  module.  It  has  a  bidirectional  electrical  interface  to  the  quantum  module 
controller  and  an  electrical  output  to  the  controlled  device.  It  receives  commands  from  the 
quantum  model  controller  and  sends  control  messages  to  and  from  the  controlled  device. 
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V.1.2  Polarization  Modulator 


The  polarization  modulator  (PM)  is  an  abstract  component  that  represents  any  number  of 
devices  used  to  electronically  change  the  polarization  of  the  light  stream.  This  architecture 
conceptualizes  these  devices  as  having  some  form  of  polarization  material  that  can  be  moved. 
The  effect  is  to  change  a  known  polarization  to  into  one  of  several  output  polarizations.  The  PM 
responds  to  external  commands  to  set  the  output  polarization  to  a  fixed  level  and  cannot 
determine  the  input  polarization.  The  PM  is  an  in-line  bidirectional  optical  component  with  two 
optical  ports.  Optical  signals  arriving  at  one  of  the  ports  is  attenuated  and  polarized,  then 
propagated  to  the  other  port  after  a  defined  propagation  delay.  The  optical  output  no  longer  needs 
the  PM  fiber,  so  the  output  path  changes  to  single-mode  (SM)  optical  fiber,  which  couples  to  the 
input  of  the  next  subsystem. 

V.1.3  Single-Mode  (SM)  Optical  Fiber 

SM  fiber  is  an  optical  component  used  to  interconnect  optical  devices.  It  has  two 
bidirectional  optical  ports.  Optical  signals  arriving  at  one  port  propagate  to  the  other  port  after  a 
defined  propagation  delay  with  its  attenuation  a  function  of  the  type  and  the  length  of  the  fiber.  It 
is  a  cylindrical  optical  waveguide  made  from  a  low-loss  material,  such  as  silica  glass.  It  has  a 
core  which  guides  the  light  and  an  outer  cladding  that  reflects  the  internal  light  back  into  the 
core,  bouncing  the  light  down  the  fiber.  This  cladding  helps  to  reflect  outside  light  to  keep  in 
from  entering  the  core.  This  structure  allows  for  low  loss  over  long  distances.  The  single-mode 
of  the  fiber  comes  from  using  a  small  core  diameter  (-'10pm  @  1550nm)  and  small  numerical 
aperture  with  the  fundamental  mode  having  a  bell-shaped  spatial  distribution  similar  (Saleh  & 
Teich,  1991;  ThorLabs,  2013). 
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V.2  PM  and  Controller  Behavior 


The  controller  and  individual  components  are  sensitive  to  the  temperature  in  the 
environment  in  which  they  operate.  If  the  temperature  exceeds  defined  thresholds,  the 
components  may  become  temporarily  degraded  or  permanently  damaged  which  changes  their 
characteristics.  If  temporarily  degraded,  the  devices  may  recover  to  normal  operating  behavior 
after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  modeling  the  controller  and  module  is  to  collect  and 
understand  the  physical,  behavioral,  and  performance  characteristics  of  the  atomic  components. 
In  this  case,  the  individual  components  were  constructed  earlier  and  the  controller  was  built  as  a 
message  handler.  The  logic  for  the  controller  was  based  on  the  types  of  messages  necessary  for 
control  of  components  inside  the  module. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 
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F.5  PM  Compound  Conceptual  Model 
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Figure  209.  Pulse  Modulator  (PM)  compound  module  conceptual  model. 
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Figure  210.  Pulse  Modulator  (PM)  controller  conceptual  model 
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Table  86.  List  of  PM  Controller  messages. 


Input  Messages 

From 

Response 

PMENV 

Quantum 

controller 

Set  the  internal  controller  temperature 

PMRESET 

Quantum 

controller 

Resets  the  controller  and  clears  the  state  variables 

PM  STATUS  REQUES 

T 

Quantum 

controller 

Sends  the  controller  status 

PM  SET  HORIZONTA 

Quantum 

Sets  polarization  to  horizontal 
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L 

controller 

PMSETVERTICAL 

Quantum 

controller 

Sets  polarization  to  vertical 

PM  SET  ANTIDIAGO 
NAL 

Quantum 

controller 

Sets  polarization  to  anti-diagonal 

PMSETDIAGONAL 

Quantum 

controller 

Sets  polarization  to  diagonal 

PMSETANGLE 

Quantum 

controller 

Sets  polarization  to  a  specific  angle 

PMGETANGLE 

Quantum 

controller 

Requests  current  polarization  angle  of  the  polarization 
modulator 

Output  Messages 

To 

Content 

PMACK 

Quantum 

Controller 

Response  to  a  Reset  message 

PMSTATUS 

Quantum 

Controller 

Response  to  a  Status  Request  message 

The  conceptual  model  for  a  PM  consists  of  two  optical  input  ports  {Optini,  OptIn2},  two 
optical  output  ports  {OptOuti,  OptOuti},  one  environmental  input  port  {Evnin},  one  control 
input  port  {Ctrllni}  and  one  control  output  port  {CtrlOuti}.  The  environmental  port  allows 
external  sources  to  communicate  changes  in  the  operational  environment  to  the  module.  The 
electrical  controller  ports  allow  for  control  inputs  to  the  controller  and  responses  from  the 
module  to  the  higher  system  functions. 

In  comparison  to  the  module  layout  used  in  the  QKD  simulation  architecture  shown  in 
Fig.  1,  a  single  bidirectional  optical  connection  is  decomposed  into  an  optical  input  and  an 
optical  output  in  the  conceptual  model.  This  is  necessary  to  properly  represent  the  behavior  of 
the  device  using  the  DEVS  formalism.  The  electrical  control  port  is  also  decomposed  in  the 
model  into  an  input  port  and  an  output  port. 

When  an  optical  signal  is  sent  to  the  input  of  the  module,  a  small  portion  of  the  signal 
will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
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unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  2  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  module  components  must  calculate  the  power  of  each  incoming  optical  signal  in 
order  to  determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This 
calculation  is  made  when  the  packet  first  enters  each  of  the  components  the  module.  In  the  case 
of  optical  overpowering,  once  overpowered  a  component  will  permanently  change  attenuation. 
External  environmental  messages  sent  to  the  module  are  directed  to  individual  components  to 
convey  the  temperature  of  the  operational  environmental  so  the  module  can  determine  if  it  is 
degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  Changes  to  components 
based  on  the  temperature  determine  the  behavior  of  the  module. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation. 
This  greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat 
multiple  optical  signals  as  independent  entities. 

V.4  English-Language  Rules  for  the  Controller 
In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
controller. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  a  control  signal  arrives: 

•  Determine  the  arrival  port  of  the  signal. 
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•  Evaluate  the  content  of  the  message 

•  Generate  a  response  message  to  the  incoming  signal  (if  necessary). 

•  Generate  a  forwarded  message  to  the  appropriate  device  (if  necessary). 

•  Output  the  response  or  forwarded  message  out  the  appropriate  port. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

V.5  DEVS  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  module  controller  in  the 
boxes  and  the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled 
with  the  type  of  transition  {Aext  -  external  or  d/„^  -  internal)  and  the  significant  actions  that  take 
place  during  the  transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the 
value  of  the  time  advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the 
phase  and  an  entry  showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase 
outputs. 


State  =  {phase,  a,  store,  temperature,  overtemp, 
overpower,  currentPolarization> 


(text  CTRL/ 
class  detect 
\  /  msg 


dint/  go 
Passive 


u« 

00 


Pneeive 

A  =  0 

dextENV/  /\ 
check 
overtemp 

tas  00 


Respond 
A=ctrl  msg 


ta«0 


dext  CTRL/ 
create  out 
msg 


Figure  211.  PM  Controller  DEVS  phase  transition  diagram 
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V.6  PM  Controller  Event-Trace  Diagram 


This  section  shows  various  examples  of  messages  entering  the  controller.  The  tables  list 
the  states  the  component  proceeds  through  as  the  events  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  component,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  queue  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes.  Note  in  contrast  to  most  other  components,  the 
controller  is  very  simple  and  only  responds  to  incoming  messages;  it  does  not  generate  any 
messages  on  its  own.  There  are  two  types  of  inputs:  control  messages  and  environmental 
messages. 


Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  CurrentPolarization:  current  polarization  modulator  polarization  setting 

•  Notes:  any  notes  for  that  state 

V.  6. 1  CASE  I:  Initial  Passive  with  Single  Control  Packet  Arriving  at  Time  0 

Table  87.  Case  I  state  list. 

Notes: 


time 

state 

1-packet 

entry/ 

exit 

no  env 
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no  ext 
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temp 
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power 
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tp=0 

0 

sO 
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inf 
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c 

n 

n 
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K  6,2  CASE  II:  Initial  Passive  with  Single  Environmental  Packet  Arriving  at  Time  0 

Table  88.  Case  II  state  list. 


Notes: 


time 

state 

1-packet 

entry/ 

exit 

1  env 

phase 

no  ext 

sigma 

0  Ctrl 

store 

(X/) 

temp 

over 

temp 

over 

power 

current  polari¬ 
zation 

assume 

tp=5 

0 

sO 

entry 

passive 

inf 
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c 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 
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n 

n 

null 

0 

SI 

entry 

passive 

inf 

null 

c 

n 

n 

null 

V.  7  PM  Controller  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  seales  involved  and  the  length  of  time  neeessary  for  temperature  fluetuations. 

Definitions: 

State  =  {phase,  time  advanee,  “store”,  temperature,  “overtemp”,  “overpower”, 
“eurrentPolarization”} 

Time  advanee(state)  =  time  advanee  of  the  eurrent  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
“eurrentPolarization”  =  variable  to  store  the  current  polarization  value  of  the  polarization 
modulator 

For  the  controller  we  define: 

Parallel-DEVS  atomic  M=  {Xm,  Ym,  S,  dgxt,  Sint,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp)  is  the  set  of  input  ports  and  values; 
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Ym  =  {{p,v)  I  p  G  OutPorts,  V  G  Yp}  is  the  set  of  output  ports  and  values; 
S  =  set  of  sequential  states; 

dext  =  2  X  ^  S'  is  the  external  state  transition  function; 

^int  =  S  ^  S  is  the  internal  state  transition  function; 

Scon  =  0  X  ^  S  is  the  confluent  transition  function; 

/I  =  S  — y*  is  the  output  function; 

to  =  S  ^  U  00  or  S  ^  i? ,  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVSpMcontroller  (Xjf,  Emj  S,  Sgxt^  ^cont  to) 


where 

tp  =  transmission  time  inside  the  component 
temperature  =  current  temperature  of  the  component 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  component 
phase  =  {“passive”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
currentPolarization  =  variable  that  holds  the  current  polarization 

interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 

messagebag=  variable  that  stores  the  current  x  input  value(s)  {p,v) 

damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 

current  =  variable  that  stores  the  queue  event  being  manipulated 

ctrlOutput  =  variable  that  stores  the  output  control  message  response 

output.port  =  variable  that  holds  the  output  optical  packet  port 

store  =  variable  that  holds  values  of  the  current  input  values 

timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  event 

e  =  elapsed  time  since  last  transition  occurred 

a  =  state  variable  that  holds  the  time  to  next  transition 

ctrlMsgO  =  method  that  generates  a  response  message  to  received  control  messages 
messagebag_lirst()  =  method  that  returns  the  first  element  of  the  message  bag 
remove_event_m()  =  method  that  remove  the  current  (x/,  time  delay,)  from  messagebag 

Every  Sext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Ctrllni”,  “Ctrlln2”  “Envin”}  with 

Xm=  {(“Ctrllni”,  Vctri),  (“Ctrlln2”,  Vctri),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 
OutPorts  =  {“CtrlOuti”,  “CtrlOut2”}  with 
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Ym  =  {(“CtrlOuti”,  Yctriouti),  (“Ctrl0ut2”,  Y ctriOutT)}  is  the  set  of  output  ports  and  values. 


phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  currentPolarization  }  =  {{“passive”, 
“respond”}  xVxRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  V) 

External  Transition  Function: 

dextiphase,  a,  store,  temperature,  overtemp,  overpower,  currentPolarization  ,e,  ((/?/, v,),.... 

(Pn,Vn)))  = 

(“respond”,  0,  store,  temperature,  overtemp,  overpower,  currentPolarization) 
if  phase  =  “passive”  and  p  =  “Ctrllni” 
ctrlOutput  =  ctrlMsg(5tore) 

if  ctrlMsg.status  =  “init”  or  “get  status”  or  “get  angle” 
outputPort  =  “CtrlOuti” 
if  CtrlMsg.status  =  “any  set  msg” 
outputPort  =  “CtrlOut2” 

(“passive”,  0,  store,  temperature,  overtemp,  overpower,  currentPolarization) 
if  phase  =  “passive”  and  p  =  “Ctrlln2” 
currentPolarization  =  messagebag.polarization 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  currentPolarization) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag. temperature 
if  temperature  >  damage.temp 
overtemp  =  “Y” 

{phase,  a-  e,  store,  temperature,  overtemp,  overpower,  currentPolarization) 
otherwise; 

Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  currentPolarization)  = 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  currentPolarization) 
if  phase  =  “respond” 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  currentPolarization)  = 
{outputPort,  CtrlOutput) 
if  phase  =  “respond” 


659 


0  (null  output) 
otherwise; 


Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  currentPolarization)  =  cr; 

V.8  PM  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 

For  the  PM  compound  module  we  define: 

Parallel-DEVS  compound N=  {X,  Y,  D,  {Md\AeD},  EIC,  EOC,  IQ 
Where: 

X=  {{p,v)  I  p  G  IPorts,  V  G  Xp}  is  the  set  of  input  ports  and  values; 

Y=  {{p,v)  I  p  G  OPorts,  V  G  Yp)  is  the  set  of  output  ports  and  values; 

D  =  set  of  component  names; 

Md  =  {Xd,  Yd,  S,  dext,  Sint,  Scon,  to)  is  a  DEVS  atomic  model; 

Xd  =  {ip,v)  I  p  G  IPorts,  V  G  Xp} ; 

Yd  =  {ip,v)  I  p  G  OPorts,  V  G  Tp} ; 

E/Cc  {((A,  ipN),{d,ipd))\  ipN  G  IPorts,  d  E  D,  ipd  G  IportSd}; 

EOC^  {((d,opd),(N,opN))\  opN  G  OPorts,  d  E  D,  opd  G  OportSd}', 

IC  c  {((a,opa),{b,iph))\a,b  G  D,  opa  G  OportSa,  ipb  G  IportSb}', 

{{d,opd),{e,ipd))  E  /trimplies  d ^e{no  feedback  loops); 

M=  an  atomic  instance  of  P-DEVS. 

N  =  a  compound  instance  of  P-DEVS. 

DEVSpm  =  (X,  Y,  D,  {Md  I  d  ED},  EIC,  EOC,  IQ 

InPorts  =  {“Ctrllni”,  “Ctrlln2”,  “Optini”,  “Optini”,  “Envin”} 

X=  {(“Ctrllm”,  v),  (“Ctrlln2”,  v),  (“Optlm”,  v),  (“OptIn2”,  v),  (“Envin”,  v)  \v  E  V} 

OutPorts  =  {“CtrlOuti”,  “CtrlOut2”,  “OptOuti”,  “OptOut2”} 
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Y=  {(“CtrlOuti”,  v),  (“CtrlOut2”,  v),  (“OptOuti”,  v),  (“OptOut2”,  v)|v  G  F} 


D  =  {controller,  polarizationmodulator,  PMfiber,  SMfiber} 

Md  controller^  M polarizationmodulator^  MpMfibert  M^Mfiber 


EIC  =  {{{N,  “Ctrllm”), (controller,  “Ctrllm”)),  {{N,  “EnvIn”),(controller,  “Envin”)),  {{N, 
“Envin”), (polarizationmodulator,  “Envin”)),  {{N,  “Envin”), (PMfiber,  “Envin”)),  {{N,  “Envin”), 
(SMfiber,  “Envin”)), ((iV,  “OptIni”),(PMfiber,  “Optlm”)),  {{N,  “OptIn2”),(SMfiber,  “OptIn2”))} 

EOC  =  {((PMfiber,  “OptOuti”),(iV,  “OptOuti”)),  ((controller,  “CtrlOuti”),(iV,  “CtrlOuti”)), 
((SMfiber,  “OptOut2”),(iV,  “OptOut2”))} 

IC  =  {((controller,  “CtrlOut2”),  (polarizationmodulator,  “Ctrllni”)),  ((polarization  modulator, 
“CtrlOuti”),(controller,  “Ctrlln2”))  , ((PMfiber,  “OptOut2”),  (polarizationmodulator,  “Optlnf’)), 
((polarizationmodulator,  “OptOutf’),  (PMfiber,  “OptIn2”)),  ((polarizationmodulator,  “OptOut2”), 
(SMfiber,  “Optlnf’)),  ((SMfiber,  “OptOuti”),  (polarizationmodulator,  “OptIn2”))} 

V.  9  PM  Controller  Use  Cases 


Initialization 

No  Optical  Output 


Ex, 

ormal  Stal 

pected  Optic 

al 

L 

Output 

J 

f 


Under  degraded 
temperature  or 
power  threshold 


Degraded  State 

Reduced  Optical 
Output 


Over  damaged 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


Damaged  State 

No  Optical  Output 


Over  damaged 
temperature  or 
power  threshold 


*Reflections  are  not  configured  to  be  effected  by  state 
^Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  212.  Component  states. 
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state  =  {phase,  a,  store,  temperature,  overtemp, 
overpower,  currentPolarization} 


dint/  go 
Passive 


dext  CTRL/ 
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Figure  213.  Controller  phase  transition  diagram 
V.  9. 1  Respond  to  a  Reset  Message 


Ineoming  reset  message  arrives  at  the  module  from  the  quantum  eontroller.  Pass  the  message  to 


the  module  eontroller.  Controller  elears  any  stored  variable  values  and  prepares  an 


aeknowledgement  message.  Response  message  is  sent  out  the  appropriate  port. 


•  Identified  Alternative  Uses  Cases 

o  Reaet  to  an  environmental  message 
o  Reaet  to  a  status  request  message 
o  Reaet  to  a  set  horizontal  message 
o  Reaet  to  a  set  vertieal  message 
o  Reaet  to  a  set  antidiagonal  message 
o  Reaet  to  a  set  diagonal  message 
o  Reaet  to  a  set  angle  message 
o  Reaet  to  a  get  angle  message 

•  Assumptions 

o  Ineoming  eleetrieal  signals  are  not  affeeted  by  eomponent  state 
V.  9.2  Respond  to  Reset  Message  End  Goals 

•  Message  properly  reeeived 

•  Controller  enters  Respond  phase  and  sets  storage  values  to  zero. 

•  Controller  forwards  Reset  Message  to  proper  eomponent(s)  as  neeessary 

•  Aeknowledgement  message  ereated  and  sent  out  the  appropriate  port 
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•  Controller  ends  in  Passive  phase 

V.9.3  Respond  to  an  Environmental  Packet 

Environmental  packet  arrives  at  the  controller.  Check  to  see  if  environmental  packet  temperature 
sets  the  controller  to  degraded  or  damaged  state.  Check  to  see  if  temperature  level  returns 
controller  from  degraded  state  to  normal  state.  Records  change  in  condition,  if  applicable. 
Change  controller  function  if  in  degraded  or  damaged  state,  if  necessary. 

•  Assumptions 

o  None 

V.  9. 4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 

•  Overtemperature  condition  properly  recognized  and  recorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

V.  9. 5  Respond  to  a  Status  Request  Message 

Status  Request  message  arrives  at  the  module  from  the  quantum  controller.  Module  controller 
prepares  response  message.  Response  message  is  sent  out  the  appropriate  port. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
V.  9. 6  Respond  to  Status  Request  End  Goals 

•  Control  message  received  properly 

•  Change  of  condition  or  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

V.  9. 7  Respond  to  a  Set  Horizontal  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
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V.  9. 8  Respond  to  Set  Horizontal  Message  End  Goals 

•  Set  Horizontal  message  reeeived  properly 

•  Message  reeognized  and  passed  to  the  proper  eomponent 

V.  9. 9  Respond  to  a  Set  Vertical  Message 

Ineoming  eontrol  message  arrives  at  the  module  from  the  quantum  eontroller.  Pass  the  message 
to  the  module  eontroller.  Module  eontroller  passes  eontrol  message  to  the  proper  eomponent. 

•  Assumptions 

o  Controller  has  eompleted  initialization  sequenee  at  least  onee 
V.9.10  Respond  to  Set  Vertical  Message  End  Goals 

•  Set  Vertieal  message  reeeived  properly 

•  Message  reeognized  and  passed  to  the  proper  eomponent 

V9.ll  Respond  to  a  Set  AntiDiagonal  Message 

Ineoming  eontrol  message  arrives  at  the  module  from  the  quantum  eontroller.  Pass  the  message 
to  the  module  eontroller.  Module  eontroller  passes  eontrol  message  to  the  proper  eomponent. 

•  Assumptions 

o  Controller  has  eompleted  initialization  sequenee  at  least  onee 
V.9.12  Respond  to  Set  AntiDiagonal  Message  End  Goals 

•  Set  AntiDiagonal  message  reeeived  properly 

•  Message  reeognized  and  passed  to  the  proper  eomponent 

V.9.13  Respond  to  a  Set  Diagonal  Message 

Ineoming  eontrol  message  arrives  at  the  module  from  the  quantum  eontroller.  Pass  the  message 
to  the  module  eontroller.  Module  eontroller  passes  eontrol  message  to  the  proper  eomponent. 

•  Assumptions 

o  Controller  has  eompleted  initialization  sequenee  at  least  onee 
V.9.14  Respond  to  Set  Diagonal  Message  End  Goals 

•  Set  Diagonal  message  reeeived  properly 
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•  Message  recognized  and  passed  to  polarization  controller 
V.9.15  Respond  to  a  Set  Angle  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  proper  component 
.  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
V.9.16  Respond  to  Set  Angle  Message  End  Goals 

•  Set  Angle  message  received  properly 

•  Message  recognized  and  passed  to  proper  component 

V.9.17  Respond  to  a  Get  Angle  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
V.9.18  Respond  to  Get  Angle  Message  End  Goals 

•  Get  Angle  message  received  properly 

•  Message  recognized  and  passed  to  the  proper  component 

V.IO  PM  Module  Use  Cases 
VI  0.1  Respond  to  an  Optical  Packet 

Optical  packet  arrives  at  the  module.  Pass  the  optical  packet  to  the  proper  internal  component. 

•  Assumptions 

o  Reflections  are  not  affected  by  module  or  component  state 
V.IO. 2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  sent  to  proper  internal  component 
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V.10.3  Respond  to  an  Environmental  Message 

Environmental  packet  arrives  at  the  module.  Environmental  message  is  passed  to  the  module 
controller  and  each  component  in  the  module. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
V.10.4  Respond  to  Environmental  Message  End  Goals 

•  Environmental  packet  received  properly  and  forwarded  to  each  component 
V.10.5  Respond  to  a  Control  Message 

Control  message  arrives  at  the  module.  Control  message  is  passed  to  the  module  controller. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
V.10.6  Respond  to  Environmental  Message  End  Goals 

•  Control  message  received  properly  and  forwarded  to  the  module  controller 

V.ll  PM  Test  Cases 

Each  coupled  submodule  was  tested  by  sending  messages  to  the  submodule  and  using  the 
operational  graphics  of  the  MS4ME  simulator  to  track  the  progress  of  the  message  through  the 
submodule.  The  primary  purpose  of  the  test  cases  was  testing  the  ability  of  the  coupled 
submodule  to  receive  messages,  pass  them  internally  to  the  submodule  controller  and  pass 
internal  output  to  external  ports.  The  controller  processed  these  input  messages  and  passed  an 
appropriate  message  to  the  controlled  opto-electrical  component.  The  type  of  control  message 
passed  to  each  coupled  submodule  depended  on  the  internal  components. 

•  PM  submodule  -  control  message  changes  polarization  of  polarization  controller 

These  test  cases  led  to  iterations  of  testing  and  correction.  Optical  messages  were  tracked 
through  the  internal  components  and  out  the  submodule  output.  Environmental  messages  were 
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checked  to  ensure  they  replicated  to  each  internal  component.  All  the  errors  identified  in  the 
coupled  submodules  were  problems  with  coding  the  controllers,  as  the  atomic  components 
functioned  properly  during  coupling. 

Table  4.  Summary  of  Coupled  Submodule  Behavior  Testing. 


total 

tests 

optical 

ports 

Ctrl 

port 

env 

port 

Classical  Pulse  Generator 

4 

0 

3 

1 

Polarization  Modulator 

5 

1 

3 

1 

Decoy  State  Generator 

5 

1 

3 

1 

Classical  To  Quantum 

5 

1 

3 

1 

Optical  Security  Layer 

4 

1 

2 

1 

Timing  Pulse  Generator 

5 

1 

3 

1 

Optical  Power  Monitor 

5 

1 

3 

1 
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Appendix  W  -  Decoy  State  Generator  (DSG) 

W.l  Device  Description: 

The  ideal  version  of  a  QKD  system  would  emit  single  photons,  but  existing  hardware  is  not 
capable  of  producing  on-demand  single  photons.  This  allows  eavesdroppers  the  opportunity  to 
conduct  a  ‘photon-number-splitting  attack’  (PNS)  but  Alice  and  Bob  have  countermeasures  in 
‘decoy  states.’  The  Decoy  State  Generator  (DSG)  allows  the  quantum  controller  to  randomly 
vary  the  power  of  the  optical  pulses.  This  variance,  along  with  statistic  collection,  allows  Alice 
and  Bob  to  detect  PNS  activity  in  the  quantum  channel.  The  DSG  contains  the  components 
shown  in  Fig.  1 . 


Figure  214.  Decoy  State  Generator  (DSG)  in  the  QKD  system  architecture. 

The  DSG  subsystem  contains  a  controller,  an  electronically  variable  optical  attenuator 
(EVOA),  electrical  interfaces,  and  interconnecting  single-mode  (SM)  optical  fiber.  We  briefly 
discuss  the  behavior  of  each  of  the  components  contained  within  the  module. 

W.1.1  DSG  Controller 

The  controller  is  an  electrical  device  containing  digital  and  analog  circuits  responsible  for 
controlling  the  EVOA.  It  has  a  bidirectional  electrical  interface  to  the  quantum  module  controller 
and  an  electrical  output  to  the  EVOA.  It  receives  commands  from  the  quantum  model  controller 
to  vary  the  attenuation,  creating  differing  power  levels  within  the  optical  pulses. 
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W.L2  EVOA 


The  EVOA  is  an  opto-electrical  device  containing  a  variable  attenuator  and  support 
electronics  to  vary  the  output  attenuation.  The  EVOA  attenuates  the  power  of  optical  signals  by  a 
variable  amount.  These  devices  usually  have  some  form  of  blocking  material  such  as  an  opaque 
slab  or  a  window  tilted  in  the  path  of  the  light.  This  blocking  material  is  connected  to  an  electric 
motor  controlled  by  the  higher  system  functions,  allowing  for  a  variable  amount  of  light  to  exit 
the  device  (OZOptics,  2013;  ThorEabs,  2013b).  Optical  signals  arriving  at  one  port  propagate  to 
the  other  port  after  a  defined  propagation  delay  with  the  attenuation  based  on  the  current 
controlled  value.  The  EVOA  output  couples  to  input  of  the  next  subsystem  via  SM  fiber. 

W.1.3  Single-Mode  Optical  Fiber 

SM  fiber  is  an  optical  component  used  to  interconnect  optical  devices.  It  has  two 
bidirectional  optical  ports.  Optical  signals  arriving  at  one  port  propagate  to  the  other  port  after  a 
defined  propagation  delay  with  its  attenuation  a  function  of  the  type  and  the  length  of  the  fiber.  It 
is  a  cylindrical  optical  waveguide  made  from  a  low-loss  material,  such  as  silica  glass.  It  has  a 
core  which  guides  the  light  and  an  outer  cladding  that  reflects  the  internal  light  back  into  the 
core,  bouncing  the  light  down  the  fiber.  This  cladding  helps  to  reflect  outside  light  to  keep  in 
from  entering  the  core.  This  structure  allows  for  low  loss  over  long  distances.  The  single-mode 
of  the  fiber  comes  from  using  a  small  core  diameter  (-'10pm  @  1550nm)  and  small  numerical 
aperture  with  the  fundamental  mode  having  a  bell-shaped  spatial  distribution  similar  (Saleh  & 
Teich,  1991;  ThorEabs,  2013).  SM  fiber  couples  the  EVOA  with  the  next  subsystem. 

W.2  DSG  and  Controller  Behavior 

The  controller  and  individual  components  are  sensitive  to  the  temperature  in  the 
environment  in  which  they  operate.  If  the  temperature  exceeds  defined  thresholds,  the 
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components  may  become  temporarily  degraded  or  permanently  damaged  which  changes  their 
eharacteristies.  If  temporarily  degraded,  the  deviees  may  reeover  to  normal  operating  behavior 
after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  modeling  the  eontroller  and  module  is  to  colleet  and 
understand  the  physical,  behavioral,  and  performance  eharacteristies  of  the  atomic  components. 
In  this  ease,  the  individual  eomponents  were  eonstrueted  earlier  and  the  eontroller  was  built  as  a 
message  handler.  The  logie  for  the  eontroller  was  based  on  the  types  of  messages  neeessary  for 
eontrol  of  eomponents  inside  the  module. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
ereated  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construetion  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 

fV.3  DSG  Compound  Conceptual  Model 

DSG  module 


OptOut2 


OptOuti 


Figure  215.  DSG  compound  module  conceptual  model. 
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Envin 


- ► 

CtrlOut2 


Ctrlln2 

Figure  216.  DSG  controller  conceptual  model 


Ctrllrii 

DSG  Controller 

CtrlOuti 

Table  89.  List  of  DSG  Controller  messages. 


Input  Messages 

From 

Response 

DSG_ENV 

Quantum  controller 

Set  the  internal  controller  temperature 

DSGRESET 

Quantum  controller 

Resets  the  controller  and  clears  the  state  variables 

DSGSTATUSREQUEST 

Quantum  controller 

Sends  the  controller  status 

DSGINCREASEATTEN 

Quantum  controller 

Increases  the  attenuation 

DSGDECREASEATTEN 

Quantum  controller 

Decreases  the  attenuation 

DSGSETATTEN 

Quantum  controller 

Sets  the  attenuation 

DSGGETATTEN 

Quantum  controller 

Gets  the  current  attenuation  value 

Output  Messages 

To 

Content 

DSG_ACK 

Quantum  Controller 

Response  to  a  Reset  message 

DSG  STATUS 

Quantum  Controller 

Response  to  a  Status  Request  message 

The  conceptual  model  for  a  DSG  consists  of  two  optical  input  ports  {Optini,  OptIn2}, 
two  optical  output  ports  {OptOuti,  OptOuti},  one  environmental  input  port  {Evnin},  one  control 
input  port  {Ctrllni}  and  one  control  output  port  {CtrlOuti}.  The  environmental  port  allows 
external  sources  to  communicate  changes  in  the  operational  environment  to  the  module.  The 
electrical  controller  ports  allow  for  control  inputs  to  the  controller  and  responses  from  the 
module  to  the  higher  system  functions. 
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In  comparison  to  the  module  layout  used  in  the  QKD  simulation  arehitecture  shown  in 
Fig.  1,  a  single  bidirectional  optical  connection  is  decomposed  into  an  optieal  input  and  an 
optieal  output  in  the  eonceptual  model.  This  is  neeessary  to  properly  represent  the  behavior  of 
the  device  using  the  DEVS  formalism.  The  electrical  control  port  is  also  decomposed  in  the 
model  into  an  input  port  and  an  output  port. 

When  an  optieal  signal  is  sent  to  the  input  of  the  module,  a  small  portion  of  the  signal 
will  be  instantaneously  refleeted  back  to  the  signal  souree.  Since  the  coneeptual  model 
deeomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidireetional  optieal  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  2  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  module  components  must  ealculate  the  power  of  each  incoming  optical  signal  in 
order  to  determine  if  the  deviee  will  become  damaged  due  to  excessive  power  levels.  This 
calculation  is  made  when  the  packet  first  enters  each  of  the  eomponents  the  module.  In  the  case 
of  optieal  overpowering,  once  overpowered  a  component  will  permanently  change  attenuation. 
External  environmental  messages  sent  to  the  module  are  directed  to  individual  components  to 
convey  the  temperature  of  the  operational  environmental  so  the  module  ean  determine  if  it  is 
degraded  (a  temporary  eondition)  or  damaged  (a  permanent  condition).  Changes  to  eomponents 
based  on  the  temperature  determine  the  behavior  of  the  module. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interferenee  at  the  Single  Photon  Deteetor  (SPD)  devices  in  the  QKD  system  simulation. 
This  greatly  simplifies  the  modeling  of  all  of  the  other  optieal  eomponents  which  can  treat 
multiple  optieal  signals  as  independent  entities. 
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W.4  English-Language  Rules  for  the  Controller 

In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
controller. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  a  control  signal  arrives: 

•  Determine  the  arrival  port  of  the  signal. 

•  Evaluate  the  content  of  the  message 

•  Generate  a  response  message  to  the  incoming  signal  (if  necessary). 

•  Generate  a  forwarded  message  to  the  appropriate  device  (if  necessary). 

•  Output  the  response  or  forwarded  message  out  the  appropriate  port. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

W.5  DEVS  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Eig.  4  shows  the  phases  of  the  module  controller  in  the 
boxes  and  the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled 
with  the  type  of  transition  {Aext  -  external  or  dint  -  internal)  and  the  significant  actions  that  take 
place  during  the  transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the 
value  of  the  time  advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the 
phase  and  an  entry  showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase 
outputs. 
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state  =  {phase,  o,  store,  temperature,  overtemp, 
overpower,  currentAttenuation} 


dint/  go 
Passive 


Oext  CTRL/ 
Class  detect 
msg 


Paeeive 

As0 


j  dext  ENV/ 
I  check 
:  overtemp 


% 


Respond 


dext  CTRL/ 
create  out 
msg 


Asctrl  msg 


Figure  217.  DSG  Controller  DEVS  phase  transition  diagram 

W.6  DSG  Controller  Event-Trace  Diagram 

This  section  shows  various  examples  of  messages  entering  the  controller.  The  tables  list 
the  states  the  component  proceeds  through  as  the  events  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  component,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  queue  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes.  Note  in  contrast  to  most  other  components,  the 
controller  is  very  simple  and  only  responds  to  incoming  messages;  it  does  not  generate  any 
messages  on  its  own.  There  are  two  types  of  inputs:  control  messages  and  environmental 


messages. 

Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 
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•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Current  Attenuation:  eurrent  EVOA  attenuation  setting 

•  Notes:  any  notes  for  that  state 

fV.  6. 1  CASE  I:  Initial  Passive  with  Single  Control  Packet  Arriving  at  Time  0 

Table  90.  Case  I  state  list. 


Notes: 

entry/  store  over  over  current  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  attenuation  tp=0 

1-packet  no  env  no  ext  1  Ctrl 


0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

null 

0 

si 

entry 

respond 

0 

null 

c 

n 

n 

null 

0 

si 

exit 

respond 

inf 

null 

c 

n 

n 

null 

0 

s2 

entry 

passive 

inf 

null 

c 

n 

n 

null 

W.  6.2  CASE  II:  Initial  Passive  with  Single  Environmental  Packet  Arriving  at  Time  0 

Table  91.  Case  II  state  list. 


Notes: 


time 

state 

1-packet 

entry/ 

exit 

1  env 

phase 

no  ext 

sigma 

0  Ctrl 

store 

(X/) 

temp 

over 

temp 

over 

power 

current 

attenuation 

assume 

tp=5 

0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

null 

0 

SI 

entry 

passive 

inf 

null 

c 

n 

n 

null 

W.  7  DSG  Controller  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  seales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“current Attenuation”  } 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
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“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
“currentAttenuation”  =  variable  to  store  the  current  attenuation  value  of  the  EVOA 

For  the  controller  we  define: 

Parallel-DEVS  atomic  M=  {Xm,  Ym,  S,  Sext,  Sint,  Scon,  to) 

Where: 

Xm  =  {(pa)  I  P  £  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp)  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  0  X  X^j  ^  S'  is  the  external  state  transition  function; 

Sint  =  S  ^  S  is  the  internal  state  transition  function; 

Scon  =  0  X  ^  S  is  the  confluent  transition  function; 

/I  =  S  ^  y*  is  the  output  function; 

to  =  S  ^  U  00  or  S  ^  S  +  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  of  A; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS osGcontroller  {Xm^  Ym>  S,  Sexh  Sint^  Scom  to) 


where 

tp  =  transmission  time  inside  the  component 
temperature  =  current  temperature  of  the  component 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  component 
phase  =  (“passive”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
currentAttenuation  =  variable  that  holds  the  current  attenuation 

interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 

messagebag=  variable  that  stores  the  current  x  input  value(s)  {p,v) 

damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 

current  =  variable  that  stores  the  queue  event  being  manipulated 

ctrlOutput  =  variable  that  stores  the  output  control  message  response 

output.port  =  variable  that  holds  the  output  optical  packet  port 

store  =  variable  that  holds  values  of  the  current  input  values 

timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  event 

e  =  elapsed  time  since  last  transition  occurred 
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a  =  state  variable  that  holds  the  time  to  next  transition 

etrlMsgO  =  method  that  generates  a  response  message  to  received  control  messages 
messagebag_lirst()  =  method  that  returns  the  first  element  of  the  message  bag 
remove_event_m()  =  method  that  remove  the  current  (x/,  time  delay,)  from  messagebag 

Every  Sext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Ctrllni”,  “Ctrlln2”  “Envin”}  with 

Xm  =  {(“Ctrllni”,  Vctrd,  (“Ctrlln2”,  Vctri),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 
OutPorts  =  {“CtrlOuti”,  “CtrlOut2”}  with 

Ym  =  {(“CtrlOuti”,  Yctriouti),  (“CtrlOut2”,  Y ctriOuti))  is  the  set  of  output  ports  and  values. 
phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  current  Attenuation  }  =  {{“passive”, 
“respond”}  xVxRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  V) 

External  Transition  Function: 

bextiphase,  o,  store,  temperature,  overtemp,  overpower ,  current  Attenuation  ,e,  {(pi,Vi{,,,,,  (pn,Vn  ))) 

(“respond”,  0,  store,  temperature,  overtemp,  overpower,  currentAttenuation) 
if  phase  =  “passive”  and  p  =  “Ctrllni” 
ctrlOutput  =  ctrlMsg(5tore) 

if  ctrlMsg.status  =  “init”  or  “get  status”  or  “get  attenuation” 
outputPort  =  “CtrlOuti” 

if  CtrlMsg.status  =  “increase”  or  “decrease”  or  set” 
outputPort  =  “CtrlOut2” 

(“passive”,  0,  store,  temperature,  overtemp,  overpower,  currentAttenuation) 
if  phase  =  “passive”  and  p  =  “Ctrlln2” 
currentAttenuation  =  messagebag.attenuation 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  currentAttenuation) 
if  phase  =  “passive”  and  p  —  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

{phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  currentAttenuation) 
otherwise; 

Internal  Transition  Function: 
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Sintiphase,  a,  store,  temperature,  overtemp,  overpower,  currentAttenuation)  = 
(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  currentAttenuation) 
if  phase  =  “respond” 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  currentAttenuation)  = 
(outputPort,  ctrlOutput) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  currentAttenuation)  =  cr; 

W.  8  DSG  Parallel  DE  VS  Code 


Notes: 

•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 

For  the  DSG  compound  module  we  define: 

Parallel-DEVS  compound N=  {X,  Y,  D,  {Md\  d  eD},  EIC,  EOC,  IQ 

Where: 

X=  {{p,v)  I  p  G  IPorts,  V  G  Xp)  is  the  set  of  input  ports  and  values; 

Y=  {{p,v)  I  p  G  OPorts,  V  G  Yp)  is  the  set  of  output  ports  and  values; 

D  =  set  of  component  names; 

Md  =  {Xd,  Yd,  S,  dext,  Sint,  Scon,  X,  to)  is  a  DEVS  atomic  model; 

Xd  =  {{p,v)  I  p  G  IPorts,  V  G  Xp} ; 

Yd  =  {ip,v)  I  p  G  OPorts,  V  G  Tp} ; 

E/Cc  {((A,  ipN),{d,ipd))\  ipN  G  IPorts,  d  E  D,  ipd  G  IportSd}; 
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EOC^  {{{d,opd),{N ,opn))\  opN  G  OPorts,  d  ED,  opd  E  OportSd}', 

IC  c  {((a,opa),{b,ipb))\a,b  G  D,  opa  G  OportSa,  ipb  G  IportSb}', 

{{d,opd),{e,ipd))  E  /dinplies  d ^ e{no  feedback  loops); 

M=  an  atomic  instance  of  P-DEVS. 

A^=  a  compound  instance  of  P-DEVS. 

DEVSdsg  =  (X,  Y,  D,  {Md  \  d  ED},  EIC,  EOC,  IQ 

InPorts  =  {“Ctrllni”,  “Ctrlln2”,  “Optini”,  “Optini”,  “Envin”} 

X=  {(“Ctrllm”,  v),  (“Ctrlln2”,  v),  (“Optlm”,  v),  (“OptIn2”,  v),  (“Envin”,  v)  \v  E  V} 

OutPorts  =  {“CtrlOuti”,  “CtrlOut2”,  “OptOuti”,  “OptOut2”} 

Y=  {(“CtrlOuti”,  v),  (“CtrlOut2”,  v),  (“OptOuti”,  v),  (“OptOut2”,  v)|v  G  V} 

D  =  {controller,  evoa,  SMfiberi,  SMfiber2} 

Md  Mi;o)ityQiigy,  Mg^QQ,  MsMfiberh  Ms^p}jgi-2 

EIC  =  {((V,  “CtrlIni”),(controller,  “Ctrllm”)),  ((V,  “EnvIn”),(controller,  “Envin”)),  {{N, 
“EnvIn”),(evoa,  “Envin”)),  ((V,  “EnvIn”),(SMfiberi,  “Envin”)),  ((V,  “Envin”),  (SMfiber2, 
“EnvIn”)),((V,  “OptIni”),(SMfiberi,  “Optlm”)),  ((V,  “OptIn2”),(SMfiber2,  “OptIn2”))} 

EOC  =  {((SMfiberi,  “OptOuti ”),(V,  “OptOuti”)),  ((controller,  “CtrlOuti ”),(V,  “CtrlOuti”)), 
((SMfiber2,  “OptOut2”),(V,  “OptOut2”))} 

IC  =  {((controller,  “CtrlOut2”),  (evoa,  “Ctrllni”)),  ((evoa,  “CtrlOuti”),(controller,  “Ctrlln2”)) 
,((SMfiberi,  “OptOut2”),  (evoa,  “Optini”)),  ((evoa,  “OptOuti”),  (SMfiberi,  “OptIn2”)),  ((evoa, 
“OptOut2”),  (SMfiber2,  “Optlm”)),  ((SMfiber2,  “OptOuti”),  (evoa,  “OptIn2”))} 

W.9  DSG  Controller  Use  Cases 
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•Reflections  are  not  configured  to  be  effected  by  state 
•Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  218.  Component  states. 


State  s  {phase,  a,  store,  temperature,  overtemp, 
overpower,  currentAttenuation} 
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Figure  219.  Controller  phase  transition  diagram 
W.  9. 1  Respond  to  a  Reset  Message 

Incoming  reset  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message  to 
the  module  controller.  Controller  clears  any  stored  variable  values  and  prepares  an 
acknowledgement  message.  Response  message  is  sent  out  the  appropriate  port. 


•  Identified  Alternative  Uses  Cases 

o  React  to  an  environmental  message 
o  React  to  a  status  request  message 
o  React  to  an  increase  attenuation  message 
o  React  to  a  decrease  attenuation  message 
o  React  to  a  set  attenuation  message 
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o  React  to  a  get  attenuation  message 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
W.9.2  Respond  to  Reset  Message  End  Goals 

•  Message  properly  received 

•  Controller  enters  Respond  phase  and  sets  storage  values  to  zero. 

•  Controller  forwards  Reset  Message  to  proper  component(s)  as  necessary 

•  Acknowledgement  message  created  and  sent  out  the  appropriate  port 

•  Controller  ends  in  Passive  phase 

W.9.3  Respond  to  an  Environmental  Packet 

Environmental  packet  arrives  at  the  controller.  Check  to  see  if  environmental  packet  temperature 
sets  the  controller  to  degraded  or  damaged  state.  Check  to  see  if  temperature  level  returns 
controller  from  degraded  state  to  normal  state.  Records  change  in  condition,  if  applicable. 
Change  controller  function  if  in  degraded  or  damaged  state,  if  necessary. 

•  Assumptions 

o  None 

W.9.4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 

•  Overtemperature  condition  properly  recognized  and  recorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

W.  9. 5  Respond  to  a  Status  Request  Message 

Status  Request  message  arrives  at  the  module  from  the  quantum  controller.  Module  controller 
prepares  response  message.  Response  message  is  sent  out  the  appropriate  port. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
W.9. 6  Respond  to  Status  Request  End  Goals 

•  Control  message  received  properly 

•  Change  of  condition  or  state  completed  and  recorded  properly,  if  necessary 
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•  Change  component  function  properly,  if  necessary 
W.9. 7  Respond  to  an  Increase  Attenuation  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
W. 9. 8  Respond  to  Increase  Attenuation  Message  End  Goals 

•  Increase  Attenuation  message  received  properly 

•  Message  recognized  and  passed  to  proper  component 

W. 9. 9  Respond  to  a  Decrease  Attenuation  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
W.9. 10 Respond  to  Decrease  Attenuation  Message  End  Goals 

•  Decrease  Attenuation  message  received  properly 

•  Message  recognized  and  passed  to  proper  component 

W.9.IIRespond  to  a  Set  Attenuation  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
W.9. 12 Respond  to  Set  Attenuation  Message  End  Goals 

•  Set  Attenuation  message  received  properly 

•  Message  recognized  and  passed  to  proper  component 

W.9.I3Respond  to  a  Get  Attenuation  Message 
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Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
W.9. 14 Respond  to  Get  Attenuation  Message  End  Goals 

•  Get  Attenuation  message  received  properly 

•  Message  recognized  and  passed  to  proper  component 

W.IO  DSG  Module  Use  Cases 
W,  10,1  Respond  to  an  Optical  Packet 

Optical  packet  arrives  at  the  module.  Pass  the  optical  packet  to  the  proper  internal  eomponent. 

•  Assumptions 

o  Reflections  are  not  affected  by  module  or  component  state 
W,1 0,2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  sent  to  proper  internal  component 
W,1 0,3  Respond  to  an  Environmental  Message 

Environmental  packet  arrives  at  the  module.  Environmental  message  is  passed  to  the  module 
controller  and  eaeh  component  in  the  module. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
W,10,4 Respond  to  Environmental  Message  End  Goals 

•  Environmental  paeket  received  properly  and  forwarded  to  each  component 
W,1 0,5 Respond  to  a  Control  Message 

Control  message  arrives  at  the  module.  Control  message  is  passed  to  the  module  controller. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
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W,1 0,6 Respond  to  Environmental  Message  End  Goals 

•  Control  message  reeeived  properly  and  forwarded  to  the  module  eontroller 

W.ll  DSG  Test  Cases 

Each  coupled  submodule  was  tested  by  sending  messages  to  the  submodule  and  using  the 
operational  graphics  of  the  MS4ME  simulator  to  track  the  progress  of  the  message  through  the 
submodule.  The  primary  purpose  of  the  test  cases  was  testing  the  ability  of  the  coupled 
submodule  to  receive  messages,  pass  them  internally  to  the  submodule  controller  and  pass 
internal  output  to  external  ports.  The  controller  processed  these  input  messages  and  passed  an 
appropriate  message  to  the  controlled  opto-electrical  component.  The  type  of  control  message 
passed  to  each  coupled  submodule  depended  on  the  internal  components. 

•  DSG  submodule  -  control  message  changes  attenuation  of  EVOA 

These  test  cases  led  to  iterations  of  testing  and  correction.  Optical  messages  were  tracked 
through  the  internal  components  and  out  the  submodule  output.  Environmental  messages  were 
checked  to  ensure  they  replicated  to  each  internal  component.  All  the  errors  identified  in  the 
coupled  submodules  were  problems  with  coding  the  controllers,  as  the  atomic  components 
functioned  properly  during  coupling. 

Table  4.  Summary  of  Coupled  Submodule  Behavior  Testing. 


total 

tests 

optical 

ports 

Ctrl 

port 

env 

port 

Classical  Pulse  Generator 

4 

0 

3 

1 

Polarization  Modulator 

5 

1 

3 

1 

Decoy  State  Generator 

5 

1 

3 

1 

Classical  To  Quantum 

5 

1 

3 

1 

Optical  Security  Eayer 

4 

1 

2 

1 

Timing  Pulse  Generator 

5 

1 

3 

1 

Optical  Power  Monitor 

5 

1 

3 

1 
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Appendix  X  -  Classical  To  Quantum  (CTQ) 

X.1  Device  Description: 

Optical  pulses  generated  by  the  laser  in  the  CPG  contain  millions  of  photons,  far  more 
than  required  by  QKD  protocols.  Since  single  photon  generators  are  not  available,  existing  QKD 
systems  take  these  classical-level  pulses  (meaning  they  contain  many  photons)  and  attenuate 
them  down  to  quantum-level  pulses  (meaning  less  than  one  photon)  with  an  average  photon 
count  of  0.1.  This  low  number  is  neeessary  to  achieve  the  single -photon  requirements  of  QKD. 
The  Classical  To  Quantum  subsystem  contains  the  components  shown  in  Fig.  1. 


Figure  220.  Classical  To  Quantum  (CTQ)  in  the  QKD  system  architecture. 

The  CTQ  subsystem  contains  an  electronically  variable  optical  attenuator,  a  fixed  optical 
attenuator  and  interconnecting  SM  optical  fiber.  We  briefly  discuss  the  behavior  of  each  of  the 
components  contained  within  the  module. 

24.1.1  EVOA 

The  EVOA  is  an  opto-electrical  device  containing  a  variable  attenuator  and  support 
electronics  to  vary  the  output  attenuation.  The  EVOA  attenuates  the  power  of  optical  signals  by  a 
variable  amount.  These  devices  usually  have  some  form  of  blocking  material  such  as  an  opaque 
slab  or  a  window  tilted  in  the  path  of  the  light.  This  blocking  material  is  connected  to  an  electric 
motor  controlled  by  the  higher  system  functions,  allowing  for  a  variable  amount  of  light  to  exit 
the  device  (OZOptics,  2013;  ThorEabs,  2013c).  Optical  signals  arriving  at  one  port  propagate  to 


686 


the  other  port  after  a  defined  propagation  delay  with  the  attenuation  based  on  the  current 
controlled  value. 

X,l,2  Fixed  Attenuator 

The  fixed  attenuator  is  an  optical  device  with  two  bidirectional  optical  ports  that 
attenuates  moving  through  the  component.  They  are  typically  fabricated  using  either  doped 
fibers  or  misaligned  splices.  The  alternative  build  out-style  attenuator  is  a  small  male-female 
adapter  used  to  adjust  the  level  of  attenuation  by  coupling  one  or  more  FAs  between  fiber  cables 
(ThorLabs,  2013a).  Optical  signals  arriving  at  one  port  propagate  to  the  other  port  after  a  defined 
propagation  delay.  The  output  of  the  fixed  attenuator  couples  to  the  input  of  the  isolator  in  the 
next  subsystem  using  SM  fiber. 

X.1.3  Single-Mode  Optical  Fiber 

SM  fiber  is  an  optical  component  used  to  interconnect  optical  devices.  It  has  two 
bidirectional  optical  ports.  Optical  signals  arriving  at  one  port  propagate  to  the  other  port  after  a 
defined  propagation  delay  with  its  attenuation  a  function  of  the  type  and  the  length  of  the  fiber.  It 
is  a  cylindrical  optical  waveguide  made  from  a  low-loss  material,  such  as  silica  glass.  It  has  a 
core  which  guides  the  light  and  an  outer  cladding  that  reflects  the  internal  light  back  into  the 
core,  bouncing  the  light  down  the  fiber.  This  cladding  helps  to  reflect  outside  light  to  keep  in 
from  entering  the  core.  This  structure  allows  for  low  loss  over  long  distances.  The  single-mode 
of  the  fiber  comes  from  using  a  small  core  diameter  (-'10pm  @  1550nm)  and  small  numerical 
aperture  with  the  fundamental  mode  having  a  bell-shaped  spatial  distribution  similar  (Saleh  & 
Teich,  1991;  ThorLabs,  2013b).  SM  fiber  couples  devices  within  the  module. 
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X.2  CTQ  and  Controller  Behavior 


The  controller  and  individual  components  are  sensitive  to  the  temperature  in  the 
environment  in  which  they  operate.  If  the  temperature  exceeds  defined  thresholds,  the 
components  may  become  temporarily  degraded  or  permanently  damaged  which  changes  their 
characteristics.  If  temporarily  degraded,  the  devices  may  recover  to  normal  operating  behavior 
after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  modeling  the  controller  and  module  is  to  collect  and 
understand  the  physical,  behavioral,  and  performance  characteristics  of  the  atomic  components. 
In  this  case,  the  individual  components  were  constructed  earlier  and  the  controller  was  built  as  a 
message  handler.  The  logic  for  the  controller  was  based  on  the  types  of  messages  necessary  for 
control  of  components  inside  the  module. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 
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X.3  CTQ  Compound  Conceptual  Model 
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Figure  221.  CTQ  compound  module  conceptual  model. 
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Figure  222.  CTQ  controller  conceptual  model 
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Table  92.  List  of  CTQ  Controller  messages. 


Input  Messages 

From 

Response 

CTQENV 

Quantum  controller 

Set  the  internal  controller  temperature 

CTQRESET 

Quantum  controller 

Resets  the  controller  and  clears  the  state  variables 

CTQSTATUSREQUEST 

Quantum  controller 

Sends  the  controller  status 

CTQINCREASEATTEN 

Quantum  controller 

Increases  the  attenuation 

CTQDECREASEATTEN 

Quantum  controller 

Decreases  the  attenuation 

CTQSETATTEN 

Quantum  controller 

Sets  the  attenuation 
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CTQGETATTEN 

Quantum  controller 

Gets  the  current  attenuation  value 

Output  Messages 

To 

Content 

CTQACK 

Quantum  Controller 

Response  to  a  Reset  message 

CTQ  STATUS 

Quantum  Controller 

Response  to  a  Status  Request  message 

The  conceptual  model  for  a  CTQ  consists  of  two  optical  input  ports  {Optini,  OptIn2}, 
two  optical  output  ports  {OptOuti,  OptOuti},  one  environmental  input  port  {Evnin},  one  control 
input  port  {Ctrllni}  and  one  control  output  port  {CtrlOuti}.  The  environmental  port  allows 
external  sources  to  communicate  changes  in  the  operational  environment  to  the  module.  The 
electrical  controller  ports  allow  for  control  inputs  to  the  controller  and  responses  from  the 
module  to  the  higher  system  functions. 

In  comparison  to  the  module  layout  used  in  the  QKD  simulation  architecture  shown  in 
Fig.  1,  a  single  bidirectional  optical  connection  is  decomposed  into  an  optical  input  and  an 
optical  output  in  the  conceptual  model.  This  is  necessary  to  properly  represent  the  behavior  of 
the  device  using  the  DEVS  formalism.  The  electrical  control  port  is  also  decomposed  in  the 
model  into  an  input  port  and  an  output  port. 

When  an  optical  signal  is  sent  to  the  input  of  the  module,  a  small  portion  of  the  signal 
will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  2  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  module  components  must  calculate  the  power  of  each  incoming  optical  signal  in 
order  to  determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This 
calculation  is  made  when  the  packet  first  enters  each  of  the  components  the  module.  In  the  case 
of  optical  overpowering,  once  overpowered  a  component  will  permanently  change  attenuation. 
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External  environmental  messages  sent  to  the  module  are  directed  to  individual  components  to 
convey  the  temperature  of  the  operational  environmental  so  the  module  can  determine  if  it  is 
degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  Changes  to  components 
based  on  the  temperature  determine  the  behavior  of  the  module. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation. 
This  greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat 
multiple  optical  signals  as  independent  entities. 

X.4  English-Language  Rules  for  the  Controller 
In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
controller. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  a  control  signal  arrives: 

•  Determine  the  arrival  port  of  the  signal. 

•  Evaluate  the  content  of  the  message 

•  Generate  a  response  message  to  the  incoming  signal  (if  necessary). 

•  Generate  a  forwarded  message  to  the  appropriate  device  (if  necessary). 

•  Output  the  response  or  forwarded  message  out  the  appropriate  port. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 
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X.5  DEVS  Phase  Transition  Diagram 


The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  module  eontroller  in  the 
boxes  and  the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled 
with  the  type  of  transition  (dex/  -  external  or  dint  -  internal)  and  the  significant  actions  that  take 
place  during  the  transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the 
value  of  the  time  advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the 
phase  and  an  entry  showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase 
outputs. 


State  =  {phase,  o,  store,  temperature,  overtemp, 
overpower,  currentAttenuation} 


dint/  go 
Passive 


4/ 


dcxt  CTRL/ 
Class  detect 
msg 


ta> 

00 


Paeeive 

A>0 


dext  ENV/ 
check 
overtemp 


7K 


tai 


Respond 
Asctrl  msg 


ta>0 


dext  CTRL/ 
create  out 
msg 


Figure  223.  CTQ  Controller  DEVS  phase  transition  diagram 


X.6  CTQ  Controller  Event-Trace  Diagram 


This  section  shows  various  examples  of  messages  entering  the  controller.  The  tables  list 


the  states  the  component  proceeds  through  as  the  events  are  processed.  Each  table  has  the  state 


number,  with  each  state  consisting  of;  phase,  time  until  next  transition  (sigma),  store  state 
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variable,  current  temperature  of  the  component,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  queue  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes.  Note  in  contrast  to  most  other  components,  the 

controller  is  very  simple  and  only  responds  to  incoming  messages;  it  does  not  generate  any 

messages  on  its  own.  There  are  two  types  of  inputs:  control  messages  and  environmental 
messages. 

Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Current  Attenuation:  current  EVOA  attenuation  setting 

•  Notes:  any  notes  for  that  state 

X.  6. 1  CASE  I:  Initial  Passive  with  Single  Control  Packet  Arriving  at  Time  0 

Table  93.  Case  I  state  list. 

Notes: 

entry/  store  over  over  current  assume 

time  state  exit  phase  sigma  (x/)  temp  temp  power  attenuation  tp=0 


1-packet  no  env  no  ext  1  Ctrl 


0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

null 

0 

si 

entry 

respond 

0 

null 

c 

n 

n 

null 

0 

si 

exit 

respond 

inf 

null 

c 

n 

n 

null 

0 

s2 

entry 

passive 

inf 

null 

c 

n 

n 

null 

X.  6.2  CASE  II:  Initial  Passive  with  Single  Environmental  Packet  Arriving  at  Time  0 

Table  94.  Case  II  state  list. 
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Notes: 


time 

state 

1-packet 

entry/ 

exit 

1  env 

phase 

no  ext 

sigma 

0  Ctrl 

store 

(X/) 

temp 

over 

temp 

over 

power 

current 

attenuation 

assume 

tp=5 

0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 
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n 

n 

null 

0 

SI 

entry 

passive 

inf 

null 

c 

n 

n 

null 

X.7  CTQ  Controller  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  seales  involved  and  the  length  of  time  neeessary  for  temperature  fluetuations. 

Definitions: 

State  =  {phase,  time  advanee,  “store”,  temperature,  “overtemp”,  “overpower”, 
“eurrent Attenuation”  } 

Time  advanee(state)  =  time  advanee  of  the  eurrent  state 
Time  delay  =  time  advanee  stored  in  queue  for  event  i 
e  =  elapsed  time  sinee  last  transition  oeeurred 
“store”  =  state  variable  that  stores  the  eurrent  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
“currentAttenuation”  =  variable  to  store  the  current  attenuation  value  of  the  EVOA 

For  the  controller  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  dgxt,  Sint,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp]  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp}  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  0  X  ^  5*  is  the  external  state  transition  function; 

Sint  =  5*  ^  S'  is  the  internal  state  transition  function; 

Scon  =  2  X  S  is  the  confluent  transition  function; 

/I  =  S  ^  T*  is  the  output  function; 

ta  =  S^R7Dcoor:S^R,  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 
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Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVScTQcontroller  (-Xm?  ^ext^  ^intt  ^com  1,  to) 


where 

tp  =  transmission  time  inside  the  component 

temperature  =  current  temperature  of  the  component 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  component 

phase  =  {“passive”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
currentAttenuation  =  variable  that  holds  the  current  attenuation 

interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 

messagebag=  variable  that  stores  the  current  x  input  value(s)  (p,v) 

damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 

current  =  variable  that  stores  the  queue  event  being  manipulated 

ctrlOutput  =  variable  that  stores  the  output  control  message  response 

output.port  =  variable  that  holds  the  output  optical  packet  port 

store  =  variable  that  holds  values  of  the  current  input  values 

timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  event 

e  =  elapsed  time  since  last  transition  occurred 

a  =  state  variable  that  holds  the  time  to  next  transition 

ctrlMsgO  =  method  that  generates  a  response  message  to  received  control  messages 
messagebag_lirst()  =  method  that  returns  the  first  element  of  the  message  bag 
remove_event_m()  =  method  that  remove  the  current  (x/,  time  delay,)  from  messagebag 

Every  Sext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Ctrllni”,  “Ctrlln2”  “Envin”}  with 

Xm  =  {(“Ctrllni”,  Vctri),  (“Ctrlln2”,  Vctri),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 
OutPorts  =  {“CtrlOuti”,  “CtrlOut2”}  with 

Ym  =  {(“CtrlOuti”,  Yctriouti),  (“CtrlOut2”,  Y ctriOuti))  is  the  set  of  output  ports  and  values. 
phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  currentAttenuation  }  =  {{“passive”, 
“respond”}  xVxRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  V) 

External  Transition  Function: 
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Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  currentAttenuation  ,e,  {{pi,Vi),....  (p„,v„))) 

(“respond”,  0,  store,  temperature,  overtemp,  overpower,  currentAttenuation) 
if  phase  =  “passive”  and  p  =  “Ctrllni” 
ctrlOutput  =  etrlMsg(5tore) 

if  ctrlMsg.status  =  “init”  or  “get  status”  or  “get  attenuation” 
outputPort  =  “CtrlOuti” 

if  CtrlMsg.status  =  “inerease”  or  “deerease”  or  set” 
outputPort  =  “CtrlOut2” 

(“passive”,  0,  store,  temperature,  overtemp,  overpower,  currentAttenuation) 
if  phase  =  “passive”  and  p  =  “Ctrlln2” 
currentAttenuation  =  messagebag.attenuation 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  currentAttenuation) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage.temp 
overtemp  =  “Y” 

{phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  currentAttenuation) 
otherwise; 

Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  currentAttenuation)  = 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  currentAttenuation) 
if  phase  =  “respond” 

Confluence  Function: 


dconis,  ta{s),  x)  =  SextiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  currentAttenuation)  = 
{outputPort,  CtrlOutput) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

ta{phase,  a,  store,  temperature,  overtemp,  overpower,  currentAttenuation)  =  cr; 
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X.8  CTQ  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 

For  the  CTQ  compound  module  we  define: 

Parallel-DEVS  compound N=  {X,  Y,  D,  {Md\AED},  EIC,  EOC,  IQ 
Where: 

X=  {{p,v)  I  p  G  IPorts,  V  G  Xp}  is  the  set  of  input  ports  and  values; 

Y=  {{p,v)  I  p  G  OPorts,  V  G  Yp]  is  the  set  of  output  ports  and  values; 

D  =  set  of  component  names; 

Md  =  {Xd,  Yd,  S,  dext,  Sint,  Scon,  to)  is  a  DEVS  atomic  model; 

Xd  =  {ip,v)  I  p  G  IPorts,  V  EXp}-, 

Yd  =  {ip,v)  I  p  G  OPorts,  vEYp}-, 

EICc  {((V  ipN),(d,ipd))\  ipN  £  IPorts,  d  E  D,  ipd  E  IportSd}; 

EOC^  {{{d,opd),{N ,opNj)\  opN  G  OPorts,  d  ED,  opd  G  OportSd}', 

IC  c  {((a,opa),{b,ipb))\a,b  G  D,  opa  G  OportSa,  ipb  G  IportSb)', 

{{d,opd),{e,ipd))  G  /^implies  d ^e{no  feedback  loops); 

M=  an  atomic  instance  of  P-DEVS. 

N  =  a  compound  instance  of  P-DEVS. 

DEVSctq  =  (X,  Y,  D,  {Md  \  d  ED},  EIC,  EOC,  IQ 

InPorts  =  {“Ctrllni”,  “Ctrlln2”,  “Optlnf’,  “Optini”,  “Envin”} 

X=  {(“Ctrllm”,  v),  (“Ctrlln2”,  v),  (“Optlm”,  v),  (“OptIn2”,  v),  (“Envin”,  v)  \v  E  V} 

OutPorts  =  {“CtrlOuti”,  “CtrlOut2”,  “OptOuti”,  “OptOut2”} 

Y=  {(“CtrlOuti”,  v),  (“CtrlOut2”,  v),  (“OptOutf’,  v),  (“OptOut2”,  v)|v  G  V} 

D  =  {controller,  evoa,  fixedattenuator,  SMfiberi,  SMfiber2,  SMfibers} 

Md  Mcontroller,  Meyoa,  M fixedattenuator,  MSMfiberl,  MgMfiberl,  MSMfiberS 

EIC  =  {((V,  “CtrlIni”),(controller,  “Ctrllm”)),  ((V,  “EnvIn”),(controller,  “Envin”)),  ((V, 
“EnvIn”),(evoa,  “Envin”)),  ((V,  “EnvIn”),(fixedattenuator,  “Envin”)),  ((V,  “EnvIn”),(SMfiberi, 
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■Envin”)),  ((A^,  “EnvIn”),(SMfiber2,  “Envin”)),  ((A^,  “EnvIn”),(SMfiber3,  “Envin”)),  ((A^, 
■OptIni”),(SMfiberi,  “Optlm”)),  ({N,  “OptIn2”),(SMfiber3,  “0ptln2”))} 


((SMfiber3,  “0pt0ut2”),(A^,  “0pt0ut2”))} 

IC  =  {((controller,  “CtrlOut2”),(evoa,  “Ctrllni”)),  ((evoa,  “CtrlOuti”), (controller,  “Ctrlln2”)), 
((SMfiberi,  “OptOut2”),(6''0^5  “Optini”)),  ((evoa,  “OptOuti”),(SMfiberi,  “OptIn2”)),  ((evoa, 
“OptOut2”),(SMfiber2,  “Optini”)),  ((SMfiber2,  “OptOuti”),(evoa,  “OptIn2”)),  ((SMfiber2, 
“OptOut2”),(fixedattenuator,  “Optini”)),  ((fixedattenuator,  “OptOuti”),(SMfiber2,  “OptIn2”)), 
((fixedattenuator,  “OptOut2”),(SMfiber3,  “Optini”)),  ((SMfiber3,  “OptOuti”),(fixedattenuator, 
“OptIn2”))} 


X.9  CTQ  Controller  Use  Cases 


X.9.1  Respond  to  a  Quantum  Controller  Message 


Under  degraded 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


*Reflections  are  not  configured  to  be  effected  by  state 
’^Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  224.  Component  states. 
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state  «  {phase,  a,  store,  temperature,  overtemp, 
overpower,  currentAttenuation} 


dexi  CTRL/ 
class  detect 

\]/  mtg 


dint/  go 
Passive 


Paeeive 

A«0 

dext  ENV/  /  \ 
check 
overtemp 
tas  » 


Respond 


A=ctrl  msg 


dext  CTRL/ 
create  out 
msg 


Figure  225.  Controller  phase  transition  diagram 
X.  9. 2  Respond  to  a  Reset  Message 

Ineoming  reset  message  arrives  at  the  module  from  the  quantum  eontroller.  Pass  the  message  to 
the  module  eontroller.  Controller  elears  any  stored  variable  values  and  prepares  an 
aeknowledgement  message.  Response  message  is  sent  out  the  appropriate  port. 


•  Identified  Alternative  Uses  Cases 

o  Reaet  to  an  environmental  message 
o  Reaet  to  a  status  request  message 
o  Reaet  to  an  inerease  attenuation  message 
o  Reaet  to  a  deerease  attenuation  message 
o  Reaet  to  a  set  attenuation  message 
o  Reaet  to  a  get  attenuation  message 

•  Assumptions 

o  Ineoming  eleetrieal  signals  are  not  affeeted  by  eomponent  state 
X.  9. 3  Respond  to  Reset  Message  End  Goals 

•  Message  properly  reeeived 

•  Controller  enters  Respond  phase  and  sets  storage  values  to  zero. 

•  Controller  forwards  Reset  Message  to  proper  eomponent(s)  as  neeessary 

•  Aeknowledgement  message  ereated  and  sent  out  the  appropriate  port 

•  Controller  ends  in  Passive  phase 

X.  9. 4  Respond  to  an  Environmental  Packet 

Environmental  paeket  arrives  at  the  eontroller.  Cheek  to  see  if  environmental  paeket  temperature 
sets  the  eontroller  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level  returns 
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controller  from  degraded  state  to  normal  state.  Records  change  in  condition,  if  applicable. 
Change  controller  function  if  in  degraded  or  damaged  state,  if  necessary. 

•  Assumptions 

o  None 

X.  9. 5  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 

•  Overtemperature  condition  properly  recognized  and  recorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

X.  9. 6  Respond  to  a  Status  Request  Message 

Status  Request  message  arrives  at  the  module  from  the  quantum  controller.  Module  controller 
prepares  response  message.  Response  message  is  sent  out  the  appropriate  port. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
X,  9. 7  Respond  to  Status  Request  End  Goals 

•  Control  message  reeeived  properly 

•  Change  of  condition  or  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

X.  9. 8  Respond  to  an  Increase  Attenuation  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  eontroller.  Module  eontroller  passes  control  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
X. 9. 9  Respond  to  Increase  Attenuation  Message  End  Goals 

•  Increase  Attenuation  message  received  properly 

•  Message  recognized  and  passed  to  proper  component 

X.9.I0  Respond  to  a  Decrease  Attenuation  Message 
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Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
X,9.11  Respond  to  Decrease  Attenuation  Message  End  Goals 

•  Decrease  Attenuation  message  received  properly 

•  Message  recognized  and  passed  to  proper  component 

X.9.12  Respond  to  a  Set  Attenuation  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  eontroller.  Module  eontroller  passes  eontrol  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
X.9.13  Respond  to  Set  Attenuation  Message  End  Goals 

•  Set  Attenuation  message  received  properly 

•  Message  recognized  and  passed  to  proper  component 

X.9.14  Respond  to  a  Get  Attenuation  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
X.9.15  Respond  to  Get  Attenuation  Message  End  Goals 

•  Get  Attenuation  message  received  properly 

•  Message  recognized  and  passed  to  proper  eomponent 

X.10  CTQ  Module  Use  Cases 
X.10.1  Respond  to  an  Optical  Packet 
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Optical  packet  arrives  at  the  module.  Pass  the  optieal  packet  to  the  proper  internal  component. 

•  Assumptions 

o  Reflections  are  not  affeeted  by  module  or  component  state 
X.10.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  sent  to  proper  internal  component 
X.10.3  Respond  to  an  Environmental  Message 

Environmental  packet  arrives  at  the  module.  Environmental  message  is  passed  to  the  module 
controller  and  eaeh  eomponent  in  the  module. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  eomponent  state 
X.10.4  Respond  to  Environmental  Message  End  Goals 

•  Environmental  packet  received  properly  and  forwarded  to  each  component 
X.10.5  Respond  to  a  Control  Message 

Control  message  arrives  at  the  module.  Control  message  is  passed  to  the  module  controller. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
X.10.6  Respond  to  Environmental  Message  End  Goals 

•  Control  message  reeeived  properly  and  forwarded  to  the  module  eontroller 

X.ll  CTQ  Test  Cases 

Each  coupled  submodule  was  tested  by  sending  messages  to  the  submodule  and  using  the 
operational  graphies  of  the  MS4ME  simulator  to  traek  the  progress  of  the  message  through  the 
submodule.  The  primary  purpose  of  the  test  cases  was  testing  the  ability  of  the  eoupled 
submodule  to  reeeive  messages,  pass  them  internally  to  the  submodule  controller  and  pass 
internal  output  to  external  ports.  The  eontroller  proeessed  these  input  messages  and  passed  an 
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appropriate  message  to  the  controlled  opto-electrical  component.  The  type  of  control  message 
passed  to  each  coupled  submodule  depended  on  the  internal  components. 

•  CTQ  submodule  -  control  message  changes  attenuation  of  EVOA 
These  test  cases  led  to  iterations  of  testing  and  correction.  Optical  messages  were  tracked 
through  the  internal  components  and  out  the  submodule  output.  Environmental  messages  were 
checked  to  ensure  they  replicated  to  each  internal  component.  All  the  errors  identified  in  the 
coupled  submodules  were  problems  with  coding  the  controllers,  as  the  atomic  components 
functioned  properly  during  coupling. 

Table  4.  Summary  of  Coupled  Submodule  Behavior  Testing. 


total 

tests 

optical 

ports 

Ctrl 

port 

env 

port 

Classical  Pulse  Generator 

4 

0 

3 

1 

Polarization  Modulator 

5 

1 

3 

1 

Decoy  State  Generator 

5 

1 

3 

1 

Classical  To  Quantum 

5 

1 

3 

1 

Optical  Security  Layer 

4 

1 

2 

1 

Timing  Pulse  Generator 

5 

1 

3 

1 

Optical  Power  Monitor 

5 

1 

3 

1 
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Appendix  Y  -  Optical  Security  Layer  (OSL) 

Y.l  Device  Description: 

The  optical  security  layer  (OSL)  works  to  detect  and  limit  the  amount  of  outside  light 
entering  the  QKD  system.  The  bandpass  filter  narrows  the  incoming  light  frequencies  and  the 
circulator  routes  the  incoming  light  to  the  classical  detector.  The  detector  acts  as  the  ‘alarm’  by 
creating  an  electrical  signal  to  the  quantum  controller.  The  circulator  allows  very  little  light  to 
pass  from  port  one  to  three  and  any  that  does  is  heavily  attenuated  by  the  isolator.  The  OSL 
subsystem  contains  the  components  shown  in  Fig.  1 . 


Figure  226.  Optical  Security  Layer  (OSL)  in  the  QKD  system  architecture. 

The  OSL  subsystem  contains  a  controller,  an  isolator,  a  circulator,  a  bandpass  fdter,  a 
classical  detector,  electrical  interfaces,  and  interconnecting  SM  optical  fiber.  We  briefly  discuss 
the  behavior  of  each  of  the  components  contained  within  the  OSL. 


Y.1.1  OSL  Controller 

The  controller  is  an  electrical  device  containing  digital  and  analog  circuits  responsible  for 
monitoring  the  classical  detector.  It  has  a  bidirectional  electrical  interface  to  the  quantum  module 
controller  and  an  electrical  input  from  the  classical  detector.  It  receives  commands  from  the 
quantum  model  controller  and  stores  information  from  the  classical  detector. 
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Y.1.2  Isolator 


The  isolator  is  an  optical  device  with  two  bidirectional  optical  ports  that  passes  light  in 
the  forward  direction  while  significantly  attenuating  light  moving  in  the  opposite  direction 
(ThorLabs,  2013b).  Optical  signals  arriving  at  one  port  propagate  to  the  other  port  after  a  defined 
propagation  delay  with  the  attenuation  based  on  the  propagation  direction.  The  isolator  assures 
that  virtually  no  light  (e.g.,  reflections  or  light  from  external  sources)  enters  the  laser.  The  output 
of  the  isolator  is  coupled  to  the  input  of  the  circulator  via  SM  fiber 

Y.1.3  Circulator 

The  circulator  is  an  optical  device  with  three  bidirectional  optical  ports  that  allows  light 
to  pass  through  in  one  direction.  Light  entering  port  one  exits  port  two  with  minimal  attenuation 
but  is  highly  attenuated  leaving  port  three.  Light  entering  port  two  exits  port  three  with  minimal 
attenuation  and  is  highly  attenuated  leaving  port  one.  A  “full”  circulator  allows  light  to  enter  port 
three  and  pass  on  to  port  one  with  minimal  attenuation  but  heavily  attenuating  port  two.  A 
“quasi”  circulator  highly  attenuates  any  light  entering  port  three  at  ports  one  and  two  (ThorLabs, 
2013d).  In  the  OSL,  the  circulator  directs  light  from  the  laser  in  port  1  and  out  port  2  out  to  the 
bandpass  filter.  Light  entering  port  2  directs  to  port  3  and  on  to  the  classical  detector. 

Y.1.4  Bandpass  Filter 

The  bandpass  filter  is  an  optical  device  with  two  bidirectional  optical  ports  that  passes  the 
optical  energy  in  a  narrow  band  around  the  signal  wavelength,  Ls,  but  strongly  attenuates  other 
wavelengths  (ThorLabs,  2013a).  This  ensures  that  only  the  appropriate  signal  wavelength  leaves 
the  subsystem  while  preventing  other  sources  of  light  from  entering  the  laser.  Optical  signals 
arriving  at  one  port  propagate  to  the  other  port  after  a  defined  propagation  delay  and  are 
attenuated  based  on  the  wavelength  of  the  signal. 
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Y.  1. 5  Classical  Detector 


The  classical  detector  is  an  opto-electrical  device  containing  an  optical  photodiode  and 
support  electronics  to  generate  an  electrical  signal  proportional  to  the  power  contained  in  the 
optical  pulse  (ThorLabs,  2013c).  This  signal  connects  to  the  controller  which  stores  this 
information  and  checks  to  see  if  it  falls  below  a  predefined  threshold.  If  so,  the  controller  notifies 
the  quantum  module  controller  of  incoming  light  and  functions  as  an  alert  device. 

Y.1.6  Single-Mode  Optical  Fiber 

SM  fiber  is  an  optical  component  used  to  interconnect  optical  devices.  It  has  two 
bidirectional  optical  ports.  Optical  signals  arriving  at  one  port  propagate  to  the  other  port  after  a 
defined  propagation  delay  with  its  attenuation  a  function  of  the  type  and  the  length  of  the  fiber.  It 
is  a  cylindrical  optical  waveguide  made  from  a  low-loss  material,  such  as  silica  glass.  It  has  a 
core  which  guides  the  light  and  an  outer  cladding  that  reflects  the  internal  light  back  into  the 
core,  bouncing  the  light  down  the  fiber.  This  cladding  helps  to  reflect  outside  light  to  keep  in 
from  entering  the  core.  This  structure  allows  for  low  loss  over  long  distances.  The  single-mode 
of  the  fiber  comes  from  using  a  small  core  diameter  (-'10pm  @  1550nm)  and  small  numerical 
aperture  with  the  fundamental  mode  having  a  bell-shaped  spatial  distribution  similar  (Saleh  & 
Teich,  1991;  ThorLabs,  2013e).  SM  fiber  couples  devices  within  the  module. 

Y.2  OSL  and  Controller  Behavior 

The  controller  and  individual  components  are  sensitive  to  the  temperature  in  the 
environment  in  which  they  operate.  If  the  temperature  exceeds  defined  thresholds,  the 
components  may  become  temporarily  degraded  or  permanently  damaged  which  changes  their 
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characteristics.  If  temporarily  degraded,  the  devices  may  recover  to  normal  operating  behavior 
after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  modeling  the  controller  and  module  is  to  colleet  and 
understand  the  physieal,  behavioral,  and  performanee  eharaeteristies  of  the  atomie  eomponents. 
In  this  case,  the  individual  components  were  constructed  earlier  and  the  controller  was  built  as  a 
message  handler.  The  logie  for  the  eontroller  was  based  on  the  types  of  messages  neeessary  for 
control  of  components  inside  the  module. 

Onee  eompleted,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
ereated  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
eonstruction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 

Y.3  OSL  Compound  Conceptual  Model 


OSL  module 


Envin 


Optlrii 


OptOuti 


Optical  Security  Layer 


OptOut2 


Ctrllrii 


Optlrij 


CtrlOuti 


Figure  227.  OSE  compound  module  conceptual  model. 
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Envin 


- ► 

CtrlOut2 


Ctrlln2 

Figure  228.  OSL  controller  conceptual  model 


Ctrl  I  Pi 


CtrlOuti 


Table  95.  List  of  OSL  Controller  messages. 


Input  Messages 

From 

Response 

OSLENV 

Quantum 

controller 

Set  the  internal  CPG  controller  temperature 

OSLRESET 

Quantum 

controller 

Resets  the  CPG  controller  and  clears  the  state  variables 

OSL  STATUS  REQUE 
ST 

Quantum 

controller 

Sends  the  CPG  controller  status  and  stored  magnitude 
value 

CDDETECTION 

Classical  Detector 

Store  the  magnitude  from  the  message 

Output  Messages 

To 

Content 

OSEACK 

Quantum 

Controller 

Response  to  a  Reset  message 

OSESTATUS 

Quantum 

Controller 

Response  to  a  Status  Request  message 

The  conceptual  model  for  the  OSL  consists  of  two  optical  input  ports  {Optini,  OptIn2}, 
two  optical  output  ports  {OptOuti,  OptOut2},  one  environmental  input  port  {Evnin},  one  control 
input  port  {Ctrllni}  and  one  control  output  port  {CtrlOuti}.  The  environmental  port  allows 
external  sources  to  communicate  changes  in  the  operational  environment  to  the  module.  The 
electrical  controller  ports  allow  for  control  inputs  to  the  controller  and  responses  from  the 
module  to  the  higher  system  functions. 

In  comparison  to  the  module  layout  used  in  the  QKD  simulation  architecture  shown  in 
Fig.  1,  a  single  bidirectional  optical  connection  is  decomposed  into  an  optical  input  and  an 
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optical  output  in  the  conceptual  model.  This  is  necessary  to  properly  represent  the  behavior  of 
the  device  using  the  DEVS  formalism.  The  electrical  control  port  is  also  decomposed  in  the 
model  into  an  input  port  and  an  output  port. 

When  an  optical  signal  is  sent  to  the  input  of  the  module,  a  small  portion  of  the  signal 
will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  2  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  module  components  must  calculate  the  power  of  each  incoming  optical  signal  in 
order  to  determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This 
calculation  is  made  when  the  packet  first  enters  each  of  the  components  the  module.  In  the  case 
of  optical  overpowering,  once  overpowered  a  component  will  permanently  change  attenuation. 
External  environmental  messages  sent  to  the  module  are  directed  to  individual  components  to 
convey  the  temperature  of  the  operational  environmental  so  the  module  can  determine  if  it  is 
degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  Changes  to  components 
based  on  the  temperature  determine  the  behavior  of  the  module. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation. 
This  greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat 
multiple  optical  signals  as  independent  entities. 

Y.4  English-Language  Rules  for  the  Controller 
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In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
controller. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  a  control  signal  arrives: 

•  Determine  the  arrival  port  of  the  signal. 

•  Evaluate  the  content  of  the  message 

•  Generate  a  response  message  to  the  incoming  signal  (if  necessary). 

•  Generate  a  forwarded  message  to  the  appropriate  device  (if  necessary). 

•  Output  the  response  or  forwarded  message  out  the  appropriate  port. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

Y.5  DEVS  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Eig.  4  shows  the  phases  of  the  module  controller  in  the 
boxes  and  the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled 
with  the  type  of  transition  {Aext  -  external  or  Amt  -  internal)  and  the  significant  actions  that  take 
place  during  the  transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the 
value  of  the  time  advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the 
phase  and  an  entry  showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase 
outputs. 
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state  =  {phase,  a,  store,  temperature,  overtemp, 
overpower,  lastCDPower} 


dint/  go 
Passive 


(text  CTRL/ 
class  detect 
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ta  = 
00 


p^eeive 
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dext  ENV/ 
check 
overtemp 

ta=  00 


ta=0 


Respond 
A=ctrl  msg 


dext  CTRL/ 
create  out 
msg 


Figure  229.  OSL  Controller  DEVS  phase  transition  diagram 

Y.6  OSL  Controller  Event-Trace  Diagram 


This  seetion  shows  various  examples  of  messages  entering  the  eontroller.  The  tables  list 
the  states  the  eomponent  proeeeds  through  as  the  events  are  proeessed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  component,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  queue  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes.  Note  in  contrast  to  most  other  components,  the 
controller  is  very  simple  and  only  responds  to  incoming  messages;  it  does  not  generate  any 
messages  on  its  own.  There  are  two  types  of  inputs:  control  messages  and  environmental 


messages. 

Explanations  for  each  column: 
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•  Time:  elapsed  time  sinee  beginning  of  the  ease 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indieates  a  transitory  state 

•  Store:  eontents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  eurrent  internal  temperature.  In  this  ease,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  LastCDPower:  shows  the  value  of  the  last  deteetion  message 

•  Notes:  any  notes  for  that  state 

Y,  6. 1  CASE  I:  Initial  Passive  with  Single  Control  Packet  Arriving  at  Time  0 

Table  96.  Case  I  state  list. 


entry/  store  over  over  Notes: 

time  state  exit  phase  sigma  (x/)  temp  temp  power  lastCD  power  assume  tp=0 

1-packet  no  env  no  ext  1  Ctrl 


0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

null 

0 

si 

entry 

respond 

0 

null 

c 

n 

n 

null 

0 

si 

exit 

respond 

inf 

null 

c 

n 

n 

null 

0 

s2 

entry 

passive 

inf 

null 

c 

n 

n 

null 

K  6.2  CASE  II:  Initial  Passive  with  Single  Environmental  Packet  Arriving  at  Time  0 

Table  97.  Case  II  state  list. 


time 

state 

1-packet 

entry/ 

exit 

1  env 

phase 

no  ext 

sigma 

0  Ctrl 

store 

(X/) 

temp 

over 

temp 

over 

power 

lastCD  power 

Notes: 

assume  tp=0 

0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

null 

0 

SI 

entry 

passive 

inf 

null 

c 

n 

n 

null 

Y.7  OSL  Controller  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  seales  involved  and  the  length  of  time  neeessary  for  temperature  fluetuations. 


712 


Definitions: 


State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”,  “lastCDPower”} 

Time  advance(state)  =  time  advance  of  the  current  state 

Time  delay  =  time  advance  stored  in  queue  for  event  i 

e  =  elapsed  time  since  last  transition  occurred 

“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
“lastCDPower”  =  variable  to  store  the  power  value  of  the  last  classical  detector  message 

For  the  controller  we  define: 

Parallel-DEVS  atomic  M=  {Xm,  Ym,  S,  dext,  Sint,  Scon,  to) 

Where: 

Xm  =  {{p,v)  I  p  G  InPorts,  v  G  Xp)  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp}  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  0  X  X^j  ^  S'  is  the  external  state  transition  function; 

Sint  =  S  —>■  S  is  the  internal  state  transition  function; 

Scon  =  2 X  Xh  Sis  the  confluent  transition  function; 

=  S  — T*  is  the  output  function; 
to  =  S  ^  U  00  or  S  ^  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVSoSLcontroller  Fm,  S,  Sextt  Sint,  Scon,  1,  to) 


where 

tp  =  transmission  time  inside  the  component 
temperature  =  current  temperature  of  the  component 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  component 
phase  =  {“passive”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
lastCDPower=  variable  that  holds  the  magnitude  of  the  last  detection  message 
interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 
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messagebag=  variable  that  stores  the  eurrent  x  input  value(s)  (p,v) 

damage,  temp  =  variable  that  holds  the  eomponent  damaged  temperature  level  parameter 

current  =  variable  that  stores  the  queue  event  being  manipulated 

ctrlOutput  =  variable  that  stores  the  output  eontrol  message  response 

output.port  =  variable  that  holds  the  output  optieal  paeket  port 

store  =  variable  that  holds  values  of  the  eurrent  input  values 

timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  event 

e  =  elapsed  time  since  last  transition  occurred 

a  =  state  variable  that  holds  the  time  to  next  transition 

ctrlMsgO  =  method  that  generates  a  response  message  to  received  control  messages 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
remove_event_m()  =  method  that  remove  the  current  (x,,  time  delay,)  from  messagebag 

Every  Sext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Ctrllni”,  “Ctrlln2”  “Envin”}  with 

Xm  =  {(“Ctrllni”,  Ertr/),  (“Ctrlln2”,  E^w),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 
OutPorts  =  {“CtrlOuti”}  with 

Ym=  {(“CtrlOuti”,  Yctriouti)  is  the  set  of  output  ports  and  values. 
phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S  =  {phase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  =  {{“passive”, 
“respond”}  xVxRx  {“Y”,  “N”}  x  {“Y”,”N”}  x  V} 

External  Transition  Function: 

Sextiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower  ,e,  ((/7„v,), . . . .  (p«,v„)))  = 
(“respond”,  0,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “passive”  and  p  =  “Ctrllni” 

CtrlOutput  =  ctrlMsg(5tore) 
if  ctrlMsg.status  =  “init”  or  “get  status” 
outputPort  =  “CtrlOuti” 

(“passive”,  0,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “passive”  and  p  =  “Ctrlln2” 
lastCDPower  =  messagebag.magnitude 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “passive”  and  p  —  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage.temp 
overtemp  =  “Y” 
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{phase,  a-  e,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
otherwise; 

Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  = 
(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  lastCDPower) 
if  phase  =  “respond” 

Confluence  Function: 


dconis,  ta{s),  x)  =  SextiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  = 
(outputPort,  ctrlOutput) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

taiphase,  a,  store,  temperature,  overtemp,  overpower,  lastCDPower)  =  cr; 

Y.8  OSL  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  seales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 

For  the  OSL  compound  module  we  define: 

Parallel-DEVS  compound N=  {X,  Y,  D,  {Md\AED},  EIC,  EOC,  IC) 

Where: 

X=  {{p,v)  I  p  G  IPorts,  V  G  Xp}  is  the  set  of  input  ports  and  values; 

Y=  {{p,v)  I  p  G  OPorts,  V  G  Yp]  is  the  set  of  output  ports  and  values; 

D  =  set  of  component  names; 
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Md  =  {Xd,  Yd,  S,  8 ext,  Sint,  Scon,  K  to)  is  a  DEVS  atomic  model; 

Xd  =  {ip,v)  I  p  G  IPorts,  vEXp}-, 

Yd  =  {ip,v)  I  p  G  OPorts,  vEYp}-, 

EIC^  {((V  ipN),{d,ipd))\  ipN  £  IPorts,  dED,  ipd  E  IportSd}; 

EOC^  {{{d,opd),{N ,opd))\  opN  G  OPorts,  dED,  opd  G  OportSd}', 

IC  c  {((a,opa),{b,iph))\a,b  G  D,  opa  G  OportSa,  ipb  G  IportSb}', 

{{d,opd),{e,ipd))  G  /trimplies  d ^e{no  feedback  loops); 

M=  an  atomic  instance  of  P-DEVS. 

N  =  a  compound  instance  of  P-DEVS. 

DEVSosl  =  (V,  F,  D,  {Md  \  d  ED},  EIC,  EOC,  IQ 

InPorts  =  {“Ctrllni”,  “Ctrlln2”,  “Optini”,  “Optini”,  “Optinj”,  “Envin”} 

X=  {(“Ctrllm”,  v),  (“Ctrlln2”,  v),  (“Optlm”,  v),  (“OptIn2”,  v),  (“Optins”,  v),  (“Envin”,  v)  \v  E  V} 

OutPorts  =  {“CtrlOuti”,  “OptOuti”,  “OptOut2”,  “OptOuts”} 

F=  {(“CtrlOuti”,  v),  (“OptOuti”,  v),  (“OptOut2”,  v),  (“OptOuts”,  v)|v  G  V} 

D  =  {controller,  isolator,  circulator,  bandpass,  classicaldetector,  SMfiberi,  SMfiber2,  SMfibers, 
SMfiber4,  SMfibers} 

Md  Mcontroller,  Xfigolator,  Mdrculator,  Mbandpass,  M classicaldetector,  MSMfiberl,  M^Mfiberl,  Ms/dfiberS,  MSMfiberd, 
MSMfiberS 

EIC  =  {((V,  “CtrlIni”),(controller,  “Ctrllni”)),  ((V,  “EnvIn”),(controller,  “Envin”)),  ((V, 
“EnvIn”),(isolator,  “Envin”)),  ((V,  “EnvIn”),(circulator,  “Envin”)),  ((V,  “Envln”),(bandpass, 
“Envin”)),  {{N,  “EnvIn”),(classicaldetector,  “Envin”)),  {{N,  “EnvIn”),(SMfiberi,  “Envin”)),  {{N, 
“EnvIn”),(SMfiber2,  “Envin”)),  ((V,  “EnvIn”),(SMfiber3,  “Envin”)),  (SMfiber4,  “Envin”)), 
(SMfibers,  “Envin”)),  {{N,  “OptIni”),(SMfiberi,  “Optlm”)),  {{N,  “OptIn2”),(SMfiber4, 
“OptIn2”))} 

EOC  =  {((SMfiberi,  “OptOuti ”),(V,  “OptOuti”)),  ((controller,  “CtrlOuti ”),(V,  “CtrlOuti”)), 
((SMfiber4,  “OptOut2”),(V,  “OptOut2”))} 

IC=  {((classicaldetector,  “CtrlOuti ”),(controller,  “Ctrlln2”)), 

((SMfiberi,  “OptOut2”),(isolator,  “Optini”)),  ((isolator,  “OptOuti”),(SMfiberi,  “OptIn2”)), 
((isolator,  “OptOut2”),(SMfiber2,  “Optini”)),  ((SMfiber2,  “OptOuti ”),(isolator,  “OptIn2”)), 
((SMfiber2,  “OptOut2”),(circulator,  “Optini”)),  ((circulator,  “OptOuti”),(SMfiber2,  “OptIn2”)), 
((circulator,  “OptOut2”),(SMfiber3,  “Optini”)),  ((SMfiber3,  “OptOuti”),(circulator,  “OptIn2”)) 
((SMfiber3,  “OptOut2”),(bandpass,  “Optini”)),  ((bandpass,  “OptOuti”),(SMfiber3,  “OptIn2”)), 
((bandpass,  “OptOut2”),(SMfiber4,  “Optini”)),  ((SMfiber4,  “OptOuti”),(bandpass,  “OptIn2”)), 
((circulator,  “OptOut3”),(SMfiber5,  “OptIn2”)),  ((SMfibers,  “OptOut2”),(circulator,  “OptIn3”)) 
((SMfibers,  “OptOuti”),(classicaldetector,  “Optini”)),  ((classicaldetector,  “OptOuti”),(SMfiber5, 
“Optlm”))} 
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Y.  9  OSL  Controller  Use  Cases 


Y.9.1  Respond  to  a  Quantum  Controller  Message 


Initialization 

No  Optical  Output 


Ex, 

ormal  Stai 

pected  Optic 

al 

L 

Output 

J 

Under  degraded 
temperature  or 
power  threshold 


Degraded  State 

Reduced  Optical 
Output 


Over  damaged 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


Damaged  State 

No  Optical  Output 


Over  damaged 
temperature  or 
power  threshold 


•Reflections  are  not  configured  to  be  effected  by  state 
•Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  230.  Component  states. 


State  s  {phase,  a,  store,  temperature,  overtemp, 
overpower,  lastCDPower} 


dext  CTRL/ 
Class  detect 
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dint/  go 
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A»0 

dext  ENV/  /\ 
check 
overtemp 
tas  CD 


Respond 
Asctrl  msg 


ia=0 


dext  CTRL/ 
create  out 
msg 


Figure  231.  Controller  phase  transition  diagram 
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Y.  9. 2  Respond  to  a  Reset  Message 

Incoming  reset  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message  to 
the  module  eontroller.  Controller  elears  any  stored  variable  values  and  prepares  an 
aeknowledgement  message.  Response  message  is  sent  out  the  appropriate  port. 

•  Identified  Alternative  Uses  Cases 

o  Reaet  to  an  environmental  message 
o  Reaet  to  a  status  request  message 
o  Reaet  to  a  fire  laser  message 

o  Reaet  to  a  elassieal  detector  pulse  deteetion  message 

•  Assumptions 

o  Ineoming  eleetrieal  signals  are  not  affeeted  by  eomponent  state 
Y.  9. 3  Respond  to  Reset  Message  En  d  Goals 

•  Message  properly  reeeived 

•  Controller  enters  Respond  phase  and  sets  storage  values  to  zero. 

•  Controller  forwards  Reset  Message  to  proper  eomponent(s)  as  neeessary 

•  Acknowledgement  message  ereated  and  sent  out  the  appropriate  port 

•  Controller  ends  in  Passive  phase 

Y.9.4  Respond  to  an  Environmental  Packet 

Environmental  paeket  arrives  at  the  eontroller.  Cheek  to  see  if  environmental  paeket  temperature 
sets  the  eontroller  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level  returns 
eontroller  from  degraded  state  to  normal  state.  Reeords  ehange  in  eondition,  if  applieable. 
Change  controller  function  if  in  degraded  or  damaged  state,  if  neeessary. 

•  Assumptions 

o  None 

Y.  9. 5  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  paeket  reeeived  properly 

•  Overtemperature  eondition  properly  reeognized  and  reeorded 

•  Change  of  state  eompleted  and  reeorded  properly,  if  neeessary 

•  Change  eomponent  funetion  properly,  if  neeessary 
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Y.  9. 6  Respond  to  a  Status  Request  Message 

Status  Request  message  arrives  at  the  module  from  the  quantum  eontroller.  Module  eontroller 
prepares  response  message.  Response  message  is  sent  out  the  appropriate  port. 

•  Assumptions 

o  Controller  has  eompleted  initialization  sequence  at  least  once 
Y.  9. 7  Respond  to  Status  Request  End  Goals 

•  Control  message  received  properly 

•  Change  of  condition  or  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

Y.9.8  Respond  to  a  Classical  Detection  Message 

Incoming  detection  message  arrives  at  the  controller  from  the  classical  detector.  Store  the 
message  contents. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
Y.9.9  Respond  to  Classical  Detection  Message  End  Goals 

•  CD  message  received  properly 

•  CD  message  values  stored  properly 

Y.IO  OSL  Module  Use  Cases 
Y.10.1  Respond  to  an  Optical  Packet 

Optical  packet  arrives  at  the  module.  Pass  the  optical  packet  to  the  proper  internal  component. 

•  Assumptions 

o  Reflections  are  not  affected  by  module  or  component  state 
Y.IO. 2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  sent  to  proper  internal  component 
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Y.10.3  Respond  to  an  Environmental  Message 

Environmental  packet  arrives  at  the  module.  Environmental  message  is  passed  to  the  module 
controller  and  each  component  in  the  module. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
Y.10.4  Respond  to  Environmental  Message  End  Goals 

•  Environmental  packet  received  properly  and  forwarded  to  each  component 
Y.10.5  Respond  to  a  Control  Message 

Control  message  arrives  at  the  module.  Control  message  is  passed  to  the  module  controller. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
Y.10.6  Respond  to  Environmental  Message  End  Goals 

•  Control  message  received  properly  and  forwarded  to  the  module  controller 

Y.ll  OSL  Test  Cases 

Each  coupled  submodule  was  tested  by  sending  messages  to  the  submodule  and  using  the 
operational  graphics  of  the  MS4ME  simulator  to  track  the  progress  of  the  message  through  the 
submodule.  The  primary  purpose  of  the  test  cases  was  testing  the  ability  of  the  coupled 
submodule  to  receive  messages,  pass  them  internally  to  the  submodule  controller  and  pass 
internal  output  to  external  ports.  The  controller  processed  these  input  messages  and  passed  an 
appropriate  message  to  the  controlled  opto-electrical  component.  The  type  of  control  message 
passed  to  each  coupled  submodule  depended  on  the  internal  components. 

•  OSE  submodule  -  no  control  message  to  change  internal  settings 

These  test  cases  led  to  iterations  of  testing  and  correction.  Optical  messages  were  tracked 
through  the  internal  components  and  out  the  submodule  output.  Environmental  messages  were 
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checked  to  ensure  they  replicated  to  each  internal  component.  All  the  errors  identified  in  the 
coupled  submodules  were  problems  with  coding  the  controllers,  as  the  atomic  components 
functioned  properly  during  coupling. 

Table  4.  Summary  of  Coupled  Submodule  Behavior  Testing. 


total 

tests 

optical 

ports 

Ctrl 

port 

env 

port 

Classical  Pulse  Generator 

4 

0 

3 

1 

Polarization  Modulator 

5 

1 

3 

1 

Decoy  State  Generator 

5 

1 

3 

1 

Classical  To  Quantum 

5 

1 

3 

1 

Optical  Security  Layer 

4 

1 

2 

1 

Timing  Pulse  Generator 

5 

1 

3 

1 

Optical  Power  Monitor 

5 

1 

3 

1 
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Appendix  Z  -  Timing  Pulse  Generator  (TPG) 

Z.l  Device  Description: 

The  optical  frames  used  by  the  QKD  system  need  a  way  to  synchronize  between  Alice 
and  Bob.  Even  the  best  timing  devices  have  error  and  other  external  timing  (e.g.  GPS)  do  not 
have  the  accuracy  necessary  for  frame  timing.  Bob  needs  to  know  with  a  high-degree  of  accuracy 
when  to  open  the  gates  windows  for  his  single  photon  detectors.  Alice  provides  this  timing  by 
injecting  a  bright  pulse  (i.e.  classical  level)  of  light  (kt  )  into  the  quantum  channel  to  start  each 
frame.  The  wave  division  multiplexer  multiplexes  the  TPG  timing  signal  kt,  and  the  CPG  signal 
pulse  ks.  Once  intermixed,  the  pulses  output  to  the  output  monitor  subsystem.  The  TPG  contains 
the  components  shown  in  Fig.  1. 


Figure  232.  Timing  Pulse  Generator  (TPG)  in  the  QKD  system  architecture. 

The  TPG  subsystem  contains  a  controller,  a  laser,  an  optical  polarizer,  a  fixed  attenuator, 
wave  division  multiplexer,  electrical  interfaces,  and  interconnecting  SM  optical  fiber.  We  briefly 
discuss  the  behavior  of  each  of  the  components  contained  within  the  TPG. 

Z.l.l  TPG  Controller 

The  controller  is  an  electrical  device  containing  digital  and  analog  circuits  responsible  for 
controlling  the  laser.  It  has  a  bidirectional  electrical  interface  to  the  quantum  module  controller 
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and  an  electrical  output  to  the  laser.  It  receives  commands  from  the  quantum  model  controller, 
sends  fire  commands  to  the  laser,  and  monitors  the  health  of  the  laser. 

Z,1.2  Laser 

The  laser  is  an  electro-optical  device  which  contains  an  optical  oscillator  and  emits 
coherent  light  (Saleh  &  Teich,  1991b).  It  has  an  electrical  input  to  receive  control  messages  and 
an  optical  output  to  emit  generated  pulses.  Within  the  simulation,  the  laser  creates  optical  pulses 
when  it  receives  a  “fire”  command  from  the  controller.  The  laser  generates  short-duration  laser 
pulses  (e.g.,  ImW  peak  intensity  with  a  500ps  duration)  containing  millions  of  photons 
(ThorLabs,  2013  a).  The  output  of  the  laser  couples  to  the  input  of  the  polarizer  via  SM  fiber. 

Z.1.3  Polarizer 

The  polarizer  is  an  optical  device  with  two  bidirectional  optical  ports  allowing  light  of 
one  polarization  to  pass  while  highly  attenuating  light  orthogonal  to  the  passed  light  (ThorLabs, 
2013c).  Optical  signals  arriving  at  one  port  propagate  to  the  other  port  after  a  defined 
propagation  delay  and  polarized  depending  on  the  polarizer  orientation  with  respect  to  the 
connected  fiber.  The  output  of  the  polarizer  is  coupled  to  the  input  of  the  fixed  attenuator  via  SM 
fiber. 

Z.1.4  Fixed  Attenuator 

The  fixed  attenuator  is  an  optical  device  with  two  bidirectional  optical  ports  that 
attenuates  moving  through  the  component.  They  are  typically  fabricated  using  either  doped 
fibers  or  misaligned  splices.  The  alternative  build  out-style  attenuator  is  a  small  male-female 
adapter  used  to  adjust  the  level  of  attenuation  by  coupling  one  or  more  FAs  between  fiber  cables 
(ThorLabs,  2013b).  Optical  signals  arriving  at  one  port  propagate  to  the  other  port  after  a  defined 
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propagation  delay.  The  output  of  the  fixed  attenuator  eouples  to  the  input  of  the  WDM  using  SM 
fiber. 

Z 1. 5  Wave  Division  Multiplexor  (dichroic  mirror) 

The  WDM  is  an  optieal  deviee  with  three  bidireetional  optieal  ports  used  to  eombine  (or 
split)  different  wavelengths  of  light  into  one  stream.  In  the  opposite  direetion  through  the  WDM, 
eombined  optieal  signals  are  separated  into  different  streams  and  sent  out  different  ports 
(OZOpties,  2013).  Here,  the  WDM  eombines  the  signal  and  timing  pulse.  Optieal  signals 
arriving  at  one  port  propagate  to  the  other  port  after  a  defined  propagation  delay.  The  WDM 
output  eouples  to  input  of  the  next  subsystem  via  SM  fiber. 

Z.1.6  Single-Mode  Optical  Fiber 

SM  fiber  is  an  optieal  eomponent  used  to  intereonnect  optieal  deviees.  It  has  two 
bidireetional  optieal  ports.  Optieal  signals  arriving  at  one  port  propagate  to  the  other  port  after  a 
defined  propagation  delay  with  its  attenuation  a  funetion  of  the  type  and  the  length  of  the  fiber.  It 
is  a  eylindrieal  optieal  waveguide  made  from  a  low-loss  material,  sueh  as  siliea  glass.  It  has  a 
eore  whieh  guides  the  light  and  an  outer  cladding  that  reflects  the  internal  light  back  into  the 
core,  bouncing  the  light  down  the  fiber.  This  cladding  helps  to  reflect  outside  light  to  keep  in 
from  entering  the  core.  This  structure  allows  for  low  loss  over  long  distances.  The  single-mode 
of  the  fiber  comes  from  using  a  small  core  diameter  (~10pm  @  1550nm)  and  small  numerical 
aperture  with  the  fundamental  mode  having  a  bell-shaped  spatial  distribution  similar  (Saleh  & 
Teich,  1991a;  ThorLabs,  2013d).  SM  fiber  couples  devices  within  the  module. 
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Z.2  TPG  and  Controller  Behavior 


The  controller  and  individual  components  are  sensitive  to  the  temperature  in  the 
environment  in  which  they  operate.  If  the  temperature  exceeds  defined  thresholds,  the 
components  may  become  temporarily  degraded  or  permanently  damaged  which  changes  their 
characteristics.  If  temporarily  degraded,  the  devices  may  recover  to  normal  operating  behavior 
after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  modeling  the  controller  and  module  is  to  collect  and 
understand  the  physical,  behavioral,  and  performance  characteristics  of  the  atomic  components. 
In  this  case,  the  individual  components  were  constructed  earlier  and  the  controller  was  built  as  a 
message  handler.  The  logic  for  the  controller  was  based  on  the  types  of  messages  necessary  for 
control  of  components  inside  the  module. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 
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Z.5  TPG  Compound  Conceptual  Model 


TPG  module 


Figure  233.  TPG  compound  module  conceptual  model. 


Figure  234.  TPG  controller  conceptual  model 
Table  98.  List  of  TPG  Controller  messages. 


Input  Messages 

From 

Response 

TPGENV 

Quantum 

controller 

Set  the  internal  CPG  controller  temperature 

TPGRESET 

Quantum 

controller 

Resets  the  CPG  controller  and  clears  the  state 
variables 

TPGSTATUSREQUEST 

Quantum 

controller 

Sends  the  CPG  controller  status  and  stored 
magnitude  value 

TPGEIREEASER 

Quantum 

controller 

Issues  a  single  Eire  Easer  command  to  the  laser 
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Output  Messages 

To 

Content 

TPGACK 

Quantum 

Controller 

Response  to  a  Reset  message 

TPGSTATUS 

Quantum 

Controller 

Response  to  a  Status  Request  message 

TPGEASERFIRE 

Easer 

Command  to  fire  the  laser  one  time 

The  conceptual  model  for  the  TPG  consists  of  two  optical  input  ports  {Optini,  OptIn2}, 
two  optical  output  ports  {OptOuti,  OptOuti},  one  environmental  input  port  {Evnin},  one  control 
input  port  {Ctrllni}  and  one  control  output  port  {CtrlOuti}.  The  environmental  port  allows 
external  sources  to  communicate  changes  in  the  operational  environment  to  the  module.  The 
electrical  controller  ports  allow  for  control  inputs  to  the  controller  and  responses  from  the 
module  to  the  higher  system  functions. 

In  comparison  to  the  module  layout  used  in  the  QKD  simulation  architecture  shown  in 
Fig.  1,  a  single  bidirectional  optical  connection  is  decomposed  into  an  optical  input  and  an 
optical  output  in  the  conceptual  model.  This  is  necessary  to  properly  represent  the  behavior  of 
the  device  using  the  DEVS  formalism.  The  electrical  control  port  is  also  decomposed  in  the 
model  into  an  input  port  and  an  output  port. 

When  an  optical  signal  is  sent  to  the  input  of  the  module,  a  small  portion  of  the  signal 
will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  2  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  module  components  must  calculate  the  power  of  each  incoming  optical  signal  in 
order  to  determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This 
calculation  is  made  when  the  packet  first  enters  each  of  the  components  the  module.  In  the  case 
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of  optical  overpowering,  onee  overpowered  a  eomponent  will  permanently  ehange  attenuation. 
External  environmental  messages  sent  to  the  module  are  directed  to  individual  components  to 
convey  the  temperature  of  the  operational  environmental  so  the  module  can  determine  if  it  is 
degraded  (a  temporary  eondition)  or  damaged  (a  permanent  eondition).  Changes  to  components 
based  on  the  temperature  determine  the  behavior  of  the  module. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  proeessed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation. 
This  greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  whieh  ean  treat 
multiple  optieal  signals  as  independent  entities. 

Z.4  English-Language  Rules  for  the  Controller 
In  this  seetion,  English  language  rules  are  developed  to  express  the  desired  behavior  of  the 
controller. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  whieh  exeeed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  a  control  signal  arrives: 

•  Determine  the  arrival  port  of  the  signal. 

•  Evaluate  the  content  of  the  message 

•  Generate  a  response  message  to  the  incoming  signal  (if  necessary). 

•  Generate  a  forwarded  message  to  the  appropriate  device  (if  neeessary). 

•  Output  the  response  or  forwarded  message  out  the  appropriate  port. 

When  an  environmental  message  arrives: 
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•  Update  the  Current! emp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 

Z.5  DEVS  Phase  Transition  Diagram 

The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  module  controller  in  the 
boxes  and  the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled 
with  the  type  of  transition  {Aext  -  external  or  Am  -  internal)  and  the  significant  actions  that  take 
place  during  the  transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the 
value  of  the  time  advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the 
phase  and  an  entry  showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase 
outputs. 


state  =  <phase,  o,  store,  temperature,  overtemp, 
overpower} 


dexi CTRL/ 
class  detect 
\1/  nisg 


dint/  go 
Passive 


A=0 

dext  ENV/  /\ 
check 
overtemp 

ta=  00 


Respond 
A=ctrl  msg 


ta=0 


dext  CTRL/ 
create  out 
msg 


Figure  235.  TPG  Controller  DEVS  phase  transition  diagram 

Z.6  TPG  Controller  Event-Trace  Diagram 
This  section  shows  various  examples  of  messages  entering  the  controller.  The  tables  list 
the  states  the  component  proceeds  through  as  the  events  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of;  phase,  time  until  next  transition  (sigma),  store  state 
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variable,  current  temperature  of  the  component,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  queue  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes.  Note  in  contrast  to  most  other  components,  the 

controller  is  very  simple  and  only  responds  to  incoming  messages;  it  does  not  generate  any 

messages  on  its  own.  There  are  two  types  of  inputs:  control  messages  and  environmental 
messages. 

Explanations  for  each  column: 

•  Time:  elapsed  time  since  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  case,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Notes:  any  notes  for  that  state 

Z  6.1  CASE  I:  Initial  Passive  with  Single  Control  Packet  Arriving  at  Time  0 

Table  99.  Case  I  state  list. 


entry/  store  over  over  Notes: 

time  state  exit  phase  sigma  (x/)  temp  temp  power  assume  tp=0 

1-packet  no  env  no  ext  1  Ctrl 


0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

0 

si 

entry 

respond 

0 

null 

c 

n 

n 

0 

si 

exit 

respond 

inf 

null 

c 

n 

n 

0 

s2 

entry 

passive 

inf 

null 

c 

n 

n 

Z  6.2  CASE  II:  Initial  Passive  with  Single  Environmental  Packet  Arriving  at  Time  0 
Table  100.  Case  II  state  list. 
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time 

state 

1-packet 

entry/ 

exit 

1  env 

phase 

no  ext 

sigma 

0  Ctrl 

store 

(X/) 

temp 

over 

temp 

over 

power 

Notes: 
assume  tp=0 

0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

0 

SI 

entry 

passive 

inf 

null 

c 

n 

n 

Z.  7  TPG  Controller  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”} 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 

For  the  controller  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  dgxt,  Sint,  Scon,  to) 

Where: 

Xm  =  {{p,v)  I  p  G  InPorts,  v  G  Xp}  is  the  set  of  input  ports  and  values; 

Ym  =  {ip,v)  I  P  G  OutPorts,  v  G  Yp}  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

X* 

Sext  =  2  X  ^  S'  is  the  external  state  transition  function; 

Sint  =  S  —>■  S  is  the  internal  state  transition  function; 

X* 

Scon  =  0  X  ^  S  is  the  confluent  transition  function; 

/I  =  S  ^  T*  is  the  output  function; 

R 

ta  =  S  —>■  ‘’UooorS— >•  0*^®  is  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xft  =  a  set  of  bags  over  elements  of  X; 

M=  an  atomic  instance  of  P-DEVS. 
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DEVSTPGcontroller  ^9  ^ext>)  ^int^  ^con^  1,  to) 


where 

tp  =  transmission  time  inside  the  eomponent 
temperature  =  eurrent  temperature  of  the  component 

phase  =  control  state  that  keeps  track  of  the  internal  phase  of  the  component 
phase  =  {“passive”,  “respond”} 

overtemp  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 

overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 

interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 

messagebag=  variable  that  stores  the  current  x  input  value(s)  {p,v) 

damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 

current  =  variable  that  stores  the  queue  event  being  manipulated 

ctrlOutput  =  variable  that  stores  the  output  control  message  response 

output.port  =  variable  that  holds  the  output  optical  packet  port 

store  =  variable  that  holds  values  of  the  current  input  values 

timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  event 

e  =  elapsed  time  since  last  transition  occurred 

a  =  state  variable  that  holds  the  time  to  next  transition 

ctrlMsgO  =  method  that  generates  a  response  message  to  received  control  messages 
messagebag_first()  =  method  that  returns  the  first  element  of  the  message  bag 
remove_event_m()  =  method  that  remove  the  current  (x,,  time  delay,)  from  messagebag 

Every  Sext  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Ctrllni”,  “Ctrlln2”  “Envin”}  with 

Xm=  {(“Ctrllni”,  Vctri),  (“Ctrlln2”,  E^r/),  (“Envin”,  Venv)}  is  the  set  of  input  ports  and  values. 
OutPorts  =  {“CtrlOuti”,  “CtrlOut2”}  with 

Ym  =  {(“CtrlOuti”,  Yctriouti),  (“CtrlOut2”,  Y ctriOuti)}  is  the  set  of  output  ports  and  values. 
phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 


S=  {phase,  a,  store,  temperature,  overtemp,  overpower)  =  {{“passive”,  “respond”}  x 
Rx  {“Y”,  “N”}  X  {“Y”,”N”}} 


K 


X  Ex 


External  Transition  Function: 

dextiphase,  a,  store,  temperature,  overtemp,  overpower, e,  ((/7„v,),....  (pn,v„)y)  = 
(“respond”,  0,  store,  temperature,  overtemp,  overpower) 
if  phase  =  “passive”  and  p  =  “Ctrllni” 
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ctrlOutput  =  ctrlMsg(5tore) 
if  ctrlMsg.status  =  “init”  or  “get  status” 
outputPort  =  “CtrlOuti” 
if  CtrlMsg.status  =  “fire  laser” 
outputPort  =  “CtrlOut2” 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower) 
if  phase  =  “passive”  and  p  =  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage,  temp 
overtemp  =  “Y” 

{phase,  a-  e,  store,  temperature,  overtemp,  overpower) 
otherwise; 

Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower)  = 
(“passive”,  oo,  store,  temperature,  overtemp,  overpower) 
if  phase  =  “respond” 

Confluence  Function: 

Scon{s,  ta{s),  x)  =  dextiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower)  = 
{outputPort,  CtrlOutput) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

ta{phase,  a,  store,  temperature,  overtemp,  overpower)  =  cr; 

Z.8  TPG  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of 
the  environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same 
delay  time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 
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For  the  TPG  compound  module  we  define: 


Parallel-DEVS  compound N=  {X,  Y,  D,  {Md\  d  ED),  EIC,  EOC,  IC) 

Where: 

X=  {{p,v)  I  p  G  IPorts,  V  G  Xp}  is  the  set  of  input  ports  and  values; 

Y=  {{p,v)  I  p  G  OPorts,  V  G  fp}  is  the  set  of  output  ports  and  values; 

D  =  set  of  component  names; 

Md  =  {Xd,  Yd,  S,  6 ext,  dint,  dcon,  K  ta)  is  a  DEVS  atomic  model; 

Xd  =  {{p,v)  I  p  G  IPorts,  vEXp}-, 

Yd  =  {ip,v)  I  p  G  OPorts,  V  G  7p}; 

EIC—  {((V  ipN),{d,ip^)\  ipN  G  IPorts,  d  ED,  ipd  G  IportSd}', 

EOC—  {{{d,opd),{N,opN))\  opN  G  OPorts,  d  E  D,  opd^  OportSd}', 

IC  —  {((a,opa),{b,ipb))\a,b  G  D,  opa  G  OportSa,  ipb  G  IportSb}', 

{{d,opd),{e,ipd))  G  IC  implies  di^e  (no  feedback  loops); 

M=  an  atomic  instance  of  P-DEVS. 

N  =  a  compound  instance  of  P-DEVS. 

DEVStpg  =  (X,  Y,  D,  {Md  \  d  ED},  EIC,  EOC,  IC) 

InPorts  =  {“Ctrllm”,  “Ctrlln2”,  “Optlm”,  “OptIn2”,  “Optinj”,  “Envin”} 

X=  {(“Ctrllm”,  v),  (“Ctrlln2”,  v),  (“Optlm”,  v),  (“Optlm”,  v),  (“Optlm”,  v),  (“Envin”,  v)\vEV} 

OutPorts  =  {“CtrlOuti”,  “OptOutf’,  “OptOut2”,  “OptOuts”} 

Y=  {(“CtrlOuti”,  v),  (“OptOuti”,  v),  (“OptOut2”,  v),  (“OptOuts”,  v)|v  G  V} 

D  =  {controller,  wdm,  laser,  polarizer,  attenuator,  SMfiberi,  SMfiber2,  SMfiber3,  SMfiber4, 
SMfibers} 

Xld  Meontroller,  Xl^dm,  ^laser,  XIpolarizer,  XIattenuator,  ^^Mfiberl,  Xlgjidfiberl,  XISMfiberS,  XISMfiber4,  XISMfiberS 

EIC  =  {((V,  “Ctrllm ”),(controller,  “Ctrllm”)),  {{N,  “EnvIn”),(controller,  “Envin”)),  {{N, 
“Envln”),(wdm,  “Envin”)),  ((V,  “Envln”),(laser,  “Envin”)),  ((V,  “EnvIn”),(polarizer,  “Envin”)), 
{{N,  “EnvIn”),(attenuator,  “Envin”)),  {{N,  “EnvIn”),(SMfiberi,  “Envin”)),  {{N,  “Envin”), 
(SMfiber2,  “Envin”)),  ((V,  “EnvIn”),(SMfiber3,  “EnvIn”)),(SMfiber4,  “Envin”)),  (SMfibers, 
“Envin”)),  {{N,  “Optlm ”),(SMfiberi,  “Optlm”)),  {{N,  “OptIn2”),(SMfiber2,  “Optlm”))} 

EOC  =  {((SMfiberi,  “OptOuti”),(V,  “OptOutf’)),  ((controller,  “CtrlOuti ”),(V,  “CtrlOuti”)), 
((SMfiber2,  “OptOut2”),(V,  “OptOut2”))} 

IC=  {((laser,  “CtrlOuti”),(controller,  “Ctrllm”)), 

((SMfiberi,  “OptOut2”),(wdm,  “Optini”)),  ((wdm,  “OptOuti”),(SMfiberi,  “Optlm”)), 

((wdm,  “OptOut3”),(SMfiber2,  “Optlm”)),  ((SMfiber2,  “OptOuti”),(wdm,  “Optlm”)), 

((laser,  “OptOuti”),(SMfiber5,  “Optlm”)),  ((SMfiberj,  “OptOuti”),(laser,  “Optlm”)), 

((SMfibers,  “OptOut2”),(polarizer,  “Optlnf’)),  ((polarizer,  “OptOuti”),(SMfiber5,  “Optlm”)), 


734 


((polarizer,  “OptOut2”),(SMfiber4,  “Optlrii”)),  ((SMfiber4,  “OptOuti”), (polarizer,  “OptIn2”)), 
((SMfiber4,  “OptOut2”), (attenuator,  “Optlui”)),  ((attenuator,  “OptOuti”),(SMfiber4,  “OptIn2”)), 
((attenuator,  “OptOut2”),(SMfiber3,  “Optini”)),  ((SMfibera,  “OptOuti”),(attenuator,  “OptIn2”)), 
((SMfibers,  “OptOut2”),(wdm,  “OptIn2”)),  ((wdm,  “OptOut2”),(SMfiber3,  “OptIn2”))} 

Z.  9  TPG  Controller  Use  Cases 


Initialization 

No  Optical  Output 


Ex 

ormal  Stai 

pected  Optic 

al 

L 

Output 

J 

f 


Under  degraded 
temperature  or 
power  threshold 


Degraded  State 

Reduced  Optical 
Output 


Over  damaged 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


Damaged  State 

No  Optical  Output 


Over  damaged 
temperature  or 
power  threshold 


^Reflections  are  not  configured  to  be  effected  by  state 
^Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  236.  Component  states. 
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state  s  {phase,  a,  store,  temperature,  overtemp, 
overpower} 


dext  CTRL/ 
class  detect 
\y  msa 


dint/  go 
Passive 


ta= 

00 


A=0 

dext  ENV/  /\ 
check 
overtemp 

ta=  00 


Respond 


t8  =  0 


A=ctrl  msg 


dext  CTRL/ 
create  out 
msg 


Figure  237.  Controller  phase  transition  diagram 
Z.  9. 1  Respond  to  a  Reset  Message 

Ineoming  reset  message  arrives  at  the  module  from  the  quantum  eontroller.  Pass  the  message  to 
the  module  eontroller.  Controller  elears  any  stored  variable  values  and  prepares  an 
aeknowledgement  message.  Response  message  is  sent  out  the  appropriate  port. 


•  Identified  Alternative  Uses  Cases 

o  Reaet  to  an  environmental  message 
o  Reaet  to  a  status  request  message 
o  Reaet  to  a  fire  laser  message 

o  Reaet  to  a  elassieal  deteetor  pulse  deteetion  message 

•  Assumptions 

o  Ineoming  eleetrieal  signals  are  not  affeeted  by  eomponent  state 
Z.  9. 2  Respond  to  Reset  Message  End  Goals 

•  Message  properly  reeeived 

•  Controller  enters  Respond  phase  and  sets  storage  values  to  zero. 

•  Controller  forwards  Reset  Message  to  proper  eomponent(s)  as  neeessary 

•  Aeknowledgement  message  ereated  and  sent  out  the  appropriate  port 

•  Controller  ends  in  Passive  phase 

Z.9.3  Respond  to  an  Environmental  Packet 
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Environmental  packet  arrives  at  the  controller.  Check  to  see  if  environmental  packet  temperature 
sets  the  controller  to  degraded  or  damaged  state.  Check  to  see  if  temperature  level  returns 
controller  from  degraded  state  to  normal  state.  Records  change  in  condition,  if  applicable. 
Change  controller  function  if  in  degraded  or  damaged  state,  if  necessary. 

•  Assumptions 

o  None 

Z  9.4  Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 

•  Overtemperature  condition  properly  recognized  and  recorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

Z  9. 5  Respond  to  a  Status  Request  Message 

Status  Request  message  arrives  at  the  module  from  the  quantum  controller.  Module  controller 
prepares  response  message.  Response  message  is  sent  out  the  appropriate  port. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
Z  9. 6  Respond  to  Status  Request  End  Goals 

•  Control  message  received  properly 

•  Change  of  condition  or  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

Z  9. 7  Respond  to  a  Eire  Laser  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  laser  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
Z  9. 8  Respond  to  Eire  Laser  Message  End  Goals 

•  Eire  laser  message  received  properly 
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•  Fire  message  reeognized  and  passed  to  laser 

Z.IO  TPG  Module  Use  Cases 

Z.10.1  Respond  to  an  Optical  Packet 

Optieal  packet  arrives  at  the  module.  Pass  the  optical  packet  to  the  proper  internal  component. 

•  Assumptions 

o  Reflections  are  not  affected  by  module  or  component  state 
Z.10.2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  sent  to  proper  internal  component 
Z.10.3  Respond  to  an  Environmental  Message 

Environmental  packet  arrives  at  the  module.  Environmental  message  is  passed  to  the  module 
controller  and  each  component  in  the  module. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
Z.10.4  Respond  to  Environmental  Message  End  Goals 

•  Environmental  packet  received  properly  and  forwarded  to  each  component 
Z.IO. 5  Respond  to  a  Control  Message 

Control  message  arrives  at  the  module.  Control  message  is  passed  to  the  module  controller. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
Z.10.6  Respond  to  Environmental  Message  End  Goals 

•  Control  message  received  properly  and  forwarded  to  the  module  controller 

Z.ll  TPG  Test  Cases 

Each  coupled  submodule  was  tested  by  sending  messages  to  the  submodule  and  using  the 
operational  graphics  of  the  MS4ME  simulator  to  track  the  progress  of  the  message  through  the 
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submodule.  The  primary  purpose  of  the  test  cases  was  testing  the  ability  of  the  coupled 
submodule  to  receive  messages,  pass  them  internally  to  the  submodule  controller  and  pass 
internal  output  to  external  ports.  The  controller  processed  these  input  messages  and  passed  an 
appropriate  message  to  the  controlled  opto-electrical  component.  The  type  of  control  message 
passed  to  each  coupled  submodule  depended  on  the  internal  components. 

•  TPG  submodule  -  control  message  fires  timing  laser 
These  test  cases  led  to  iterations  of  testing  and  correction.  Optical  messages  were  tracked 
through  the  internal  components  and  out  the  submodule  output.  Environmental  messages  were 
checked  to  ensure  they  replicated  to  each  internal  component.  All  the  errors  identified  in  the 
coupled  submodules  were  problems  with  coding  the  controllers,  as  the  atomic  components 
functioned  properly  during  coupling. 

Table  4.  Summary  of  Coupled  Submodule  Behavior  Testing. 


total 

tests 

optical 

ports 

Ctrl 

port 

env 

port 

Classical  Pulse  Generator 

4 

0 

3 

1 

Polarization  Modulator 

5 

1 

3 

1 

Decoy  State  Generator 

5 

1 

3 

1 

Classical  To  Quantum 

5 

1 

3 

1 

Optical  Security  Layer 

4 

1 

2 

1 

Timing  Pulse  Generator 

5 

1 

3 

1 

Optical  Power  Monitor 

5 

1 

3 

1 
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Appendix  AA  -  Output  Power  Monitor  (OPM) 

AA.l  Device  Description: 

Alice  needs  a  way  to  verify  her  output  into  the  quantum  ehannel.  Components  ehange  as 
they  age  and  some  protoeols  may  call  for  pulses  of  differing  optical  power.  The  output  power 
monitor  (OPM)  allows  Aliee  to  sample  the  outgoing  optical  packets  by  using  a  photon  deteetor 
capable  of  counting  photons.  By  sampling  the  photon  numbers,  Alice  ean  adjust  the  EVOAs  to 
output  the  proper  optieal  power.  The  switeh  alters  the  optieal  path  by  diverting  optieal  paekets  to 
either  the  OPM  or  out  of  Aliee  into  the  quantum  ehannel.  .The  Output  Power  Monitor  subsystem 
eontains  the  eomponents  shown  in  Fig.  1 . 


Figure  238.  Output  Power  Monitor  (OPM)  in  the  QKD  system  architecture. 

The  OPM  subsystem  contains  a  controller,  a  photon  number  resolving  single  photon 
detector  (PNR-SPD),  an  optical  switch,  electrical  interfaces,  and  interconnecting  SM  optical 
fiber.  We  briefly  diseuss  the  behavior  of  eaeh  of  the  eomponents  eontained  within  the  OPM. 

AA.1.1  OPM  Controller 

The  eontroller  is  an  eleetrical  device  containing  digital  and  analog  circuits  responsible  for 
controlling  the  single  photon  detector  (SPD).  It  has  a  bidirectional  electrical  interface  to  the 
quantum  module  eontroller  and  an  eleetrieal  output  to  the  SPD.  It  reeeives  commands  from  the 
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quantum  model  controller,  receives  information  from  the  SPD,  and  monitors  the  health  of  the 
SPD. 

AA.  1.2  Photon  Number  Resolving  Single  Photon  Detector  (PNR-SPD) 

The  PNR-SPD  is  an  opto-electrical  device  containing  detection  equipment  and  support 
electronics  capable  of  counting  individual  photons.  The  PNR-SPD  has  a  single  bidirectional 
optical  port  and  a  bidirectional  electrical  port  connected  to  the  0PM  controller 

AA.1.3  Optical  Switch 

The  optical  switch  is  used  to  route  light  between  one  input  port  and  two  or  more 
input/output  ports.  The  optical  switch  is  a  bidirectional  optical  component  with  three  optical 
ports.  Optical  signals  arriving  at  one  of  the  ports  is  directed  to  one  of  the  two  input/output  ports 
and  propagated  to  the  other  port  after  a  defined  propagation  delay.  Typically,  optical  switches 
have  control  interfaces  that  allow  them  to  be  mounted  on  circuit  boards  or  have  some  other  type 
of  electrical  control  port  (DiConFiberOptics,  2013;  ThorLabs,  2013a).  The  switch  output  couples 
using  SM  fiber  to  either  the  PNR-SPD  or  the  quantum  channel. 

AA.l. 4 Single-Mode  Optical  Fiber 

SM  fiber  is  an  optical  component  used  to  interconnect  optical  devices.  It  has  two 
bidirectional  optical  ports.  Optical  signals  arriving  at  one  port  propagate  to  the  other  port  after  a 
defined  propagation  delay  with  its  attenuation  a  function  of  the  type  and  the  length  of  the  fiber.  It 
is  a  cylindrical  optical  waveguide  made  from  a  low-loss  material,  such  as  silica  glass.  It  has  a 
core  which  guides  the  light  and  an  outer  cladding  that  reflects  the  internal  light  back  into  the 
core,  bouncing  the  light  down  the  fiber.  This  cladding  helps  to  reflect  outside  light  to  keep  in 
from  entering  the  core.  This  structure  allows  for  low  loss  over  long  distances.  The  single-mode 
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of  the  fiber  eomes  from  using  a  small  eore  diameter  (-'10|a,m  @  1550nm)  and  small  numerieal 
aperture  with  the  fundamental  mode  having  a  bell-shaped  spatial  distribution  similar  (Saleh  & 
Teieh,  1991;  ThorLabs,  2013b).  SM  fiber  eouples  deviees  within  the  module. 

AA.2  0PM  and  Controller  Behavior 

The  eontroller  and  individual  eomponents  are  sensitive  to  the  temperature  in  the 
environment  in  whieh  they  operate.  If  the  temperature  exeeeds  defined  thresholds,  the 
eomponents  may  beeome  temporarily  degraded  or  permanently  damaged  whieh  ehanges  their 
eharaeteristics.  If  temporarily  degraded,  the  deviees  may  reeover  to  normal  operating  behavior 
after  the  temperature  returns  to  a  “normal”  operating  temperature. 

The  first  step  involved  with  modeling  the  eontroller  and  module  is  to  eolleet  and 
understand  the  physical,  behavioral,  and  performance  characteristics  of  the  atomic  components. 
In  this  case,  the  individual  components  were  constructed  earlier  and  the  controller  was  built  as  a 
message  handler.  The  logic  for  the  controller  was  based  on  the  types  of  messages  necessary  for 
control  of  components  inside  the  module. 

Once  completed,  the  DEVS  model  is  passed  to  the  Software  Development  team  that 
created  a  behaviorally  equivalent  C++  model  in  the  OMNeT++  simulation  environment  during 
construction  of  the  demonstration  simulation.  Comparing  the  demonstration  simulation  and 
timing  and  behavior  outputs  of  the  MS4ME  models  is  the  final  step  in  validation  testing  the 
DEVS  model. 
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AA.3  0PM  Compound  Conceptual  Model 


0PM  module 


Figure  239.  0PM  compound  module  conceptual  model. 


Figure  240.  0PM  controller  conceptual  model 


Table  101 .  List  of  0PM  Controller  messages. 


Input  Messages 

From 

Response 

OPMENV 

Quantum  controller 

Set  the  internal  controller  temperature 

OPMRESET 

Quantum  controller 

Resets  the  controller  and  clears  the  state 
variables 

OPMSTATUSREQUEST 

Quantum  controller 

Sends  the  controller  status 

0PM  SET  SWITCH  PORT 

2 

Quantum  controller 

Set  the  switch  to  port  2 

0PM  SET  SWITCH  PORT 

3 

Quantum  controller 

Set  the  switch  to  port  3 
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Output  Messages 

To 

Content 

OPMACK 

Quantum 

Controller 

Response  to  a  Reset  message 

OPMSTATUS 

Quantum 

Controller 

Response  to  a  Status  Request  message 

The  conceptual  model  for  the  0PM  consists  of  two  optical  input  ports  {Optini,  0ptln2}, 
two  optical  output  ports  {OptOuti,  OptOut2},  one  environmental  input  port  {Evnin},  one  control 
input  port  {Ctrllni}  and  one  control  output  port  {CtrlOuti}.  The  environmental  port  allows 
external  sources  to  communicate  changes  in  the  operational  environment  to  the  module.  The 
electrical  controller  ports  allow  for  control  inputs  to  the  controller  and  responses  from  the 
module  to  the  higher  system  functions. 

In  comparison  to  the  module  layout  used  in  the  QKD  simulation  architecture  shown  in 
Fig.  1,  a  single  bidirectional  optical  connection  is  decomposed  into  an  optical  input  and  an 
optical  output  in  the  conceptual  model.  This  is  necessary  to  properly  represent  the  behavior  of 
the  device  using  the  DEVS  formalism.  The  electrical  control  port  is  also  decomposed  in  the 
model  into  an  input  port  and  an  output  port. 

When  an  optical  signal  is  sent  to  the  input  of  the  module,  a  small  portion  of  the  signal 
will  be  instantaneously  reflected  back  to  the  signal  source.  Since  the  conceptual  model 
decomposes  each  bidirectional  connection  to  a  discrete  unidirectional  output  input  and  a  discrete 
unidirectional  optical  output,  this  means  that  an  optical  signal  arriving  at  Optini  in  Fig.  2  will 
instantaneously  generate  a  reflected  emitting  out  of  OptOuti . 

The  module  components  must  calculate  the  power  of  each  incoming  optical  signal  in 
order  to  determine  if  the  device  will  become  damaged  due  to  excessive  power  levels.  This 
calculation  is  made  when  the  packet  first  enters  each  of  the  components  the  module.  In  the  case 
of  optical  overpowering,  once  overpowered  a  component  will  permanently  change  attenuation. 
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External  environmental  messages  sent  to  the  module  are  directed  to  individual  components  to 
convey  the  temperature  of  the  operational  environmental  so  the  module  can  determine  if  it  is 
degraded  (a  temporary  condition)  or  damaged  (a  permanent  condition).  Changes  to  components 
based  on  the  temperature  determine  the  behavior  of  the  module. 

When  multiple  optical  signals  arrive  at  a  port  at  the  same  time,  they  will  be  processed 
each  as  independent  signals.  This  is  a  consequence  of  the  high  level  simulation  strategy  to  only 
model  interference  at  the  Single  Photon  Detector  (SPD)  devices  in  the  QKD  system  simulation. 
This  greatly  simplifies  the  modeling  of  all  of  the  other  optical  components  which  can  treat 
multiple  optical  signals  as  independent  entities. 

AA.4  English-Language  Rules  for  the  Controller 
In  this  section,  English  language  rules  are  developed  to  express  the  desired  behavior  of 
the  controller. 

•  CurrentTemp  stores  the  current  temperature.  Initially,  this  is  set  to  25  degrees  Centigrade. 

•  OverTemp  is  a  flag  which  indicates  if  the  device  is  permanently  damaged  due  to  being 
exposed  to  temperatures  which  exceed  a  defined  temperature  threshold.  Initially,  this  flag 
is  cleared. 

When  a  control  signal  arrives: 

•  Determine  the  arrival  port  of  the  signal. 

•  Evaluate  the  content  of  the  message 

•  Generate  a  response  message  to  the  incoming  signal  (if  necessary). 

•  Generate  a  forwarded  message  to  the  appropriate  device  (if  necessary). 

•  Output  the  response  or  forwarded  message  out  the  appropriate  port. 

When  an  environmental  message  arrives: 

•  Update  the  CurrentTemp  with  the  current  temperature  contained  in  the  environmental 
message. 

•  If  the  current  temperature  exceeds  the  damage  temperature  threshold,  set  the  OverTemp 
flag. 
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AA.S  DEVS  Phase  Transition  Diagram 


The  phase  transition  diagram  in  Fig.  4  shows  the  phases  of  the  module  eontroller  in  the 
boxes  and  the  transitions  represented  by  arrows  between  the  phases.  Each  transition  is  labeled 
with  the  type  of  transition  (dex/  -  external  or  dint  -  internal)  and  the  significant  actions  that  take 
place  during  the  transition.  Each  arc  has  an  entry  either  beneath  or  beside  the  arc  indicating  the 
value  of  the  time  advance  function  for  the  next  phase.  Each  box  is  labeled  with  the  name  of  the 
phase  and  an  entry  showing  either  no  lambda  output  function  for  that  phase  or  what  the  phase 
outputs. 


State  ■  {phase,  a,  store,  temperature,  overtemp, 
overpower,  ciickCount> 


dcxt  CTRL/ 
Class  detect 
\  /  msg 


dint/  go 
Passive 


ta« 


paeeive 

A>0 


dext  ENV/ 
check 
overtcmp 

ta«  00 


Respond 


taaO 


Aactrl  msg 


dext  CTRL/ 
create  out 
msg 


Figure  241.  0PM  Controller  DEVS  phase  transition  diagram 

AA.  6  0PM  Controller  Event-Trace  Diagram 

This  section  shows  various  examples  of  messages  entering  the  controller.  The  tables  list 
the  states  the  component  proceeds  through  as  the  events  are  processed.  Each  table  has  the  state 
number,  with  each  state  consisting  of:  phase,  time  until  next  transition  (sigma),  store  state 
variable,  current  temperature  of  the  component,  the  over  temperature  flag  variable  and  the  over 
power  flag  variable.  The  queue  column  shows  the  contents  of  the  queue  at  that  state,  the  contents 
of  the  store  state  variable  and  any  notes.  Note  in  contrast  to  most  other  components,  the 
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controller  is  very  simple  and  only  responds  to  incoming  messages;  it  does  not  generate  any 
messages  on  its  own.  There  are  two  types  of  inputs:  control  messages  and  environmental 
messages. 

Explanations  for  each  column: 

•  Time:  elapsed  time  sinee  beginning  of  the  case 

•  State:  shows  the  state  number  starting  with  sO,  the  start  state 

•  Phase:  shows  the  phase  for  that  state 

•  Sigma:  the  time  until  next  internal  transition.  A  0  sigma  indicates  a  transitory  state 

•  Store:  contents  of  the  store  variable  for  that  state 

•  Temp:  value  of  the  current  internal  temperature.  In  this  ease,  always  some  degree  C  value 

•  Over  Temp:  shows  the  value  of  the  over  temperature  flag  variable 

•  Over  Power:  shows  the  value  of  the  over  power  flag  variable 

•  Cliek  Count:  the  number  of  clicks  (photons)  counted  by  the  PNR  SPD 

•  Notes:  any  notes  for  that  state 

AA.6.1  CASE  I:  Initial  Passive  with  Single  Control  Packet  Arriving  at  Time  0 
Table  102.  Case  I  state  list. 


entry/  store  over  over  Notes: 

time  state  exit  phase  sigma  (x/)  temp  temp  power  click  count  assume  tp=0 

1-packet  no  env  no  ext  1  Ctrl 


0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

null 

0 

si 

entry 

respond 

0 

null 

c 

n 

n 

null 

0 

si 

exit 

respond 

inf 

null 

c 

n 

n 

null 

0 

s2 

entry 

passive 

inf 

null 

c 

n 

n 

null 

AA.6.2  CASE  II:  Initial  Passive  with  Single  Environmental  Packet  Arriving  at  Time  0 
Table  103.  Case  II  state  list. 


time 

state 

1-packet 

entry/ 

exit 

1  env 

phase 

no  ext 

sigma 

0  Ctrl 

store 

(X/) 

temp 

over 

temp 

over 

power 

click  count 

Notes: 
assume  tp=0 

0 

sO 

entry 

passive 

inf 

null 

c 

n 

n 

null 

0 

sO 

exit 

passive 

0 

null 

c 

n 

n 

null 
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0  SI 


entry  passive  inf 


nul 


null 


AA.  7  0PM  Controller  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  paeket  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 

Definitions: 

State  =  {phase,  time  advance,  “store”,  temperature,  “overtemp”,  “overpower”, 
“current Attenuation”  } 

Time  advance(state)  =  time  advance  of  the  current  state 
Time  delay  =  time  advance  stored  in  queue  for  event  i 
e  =  elapsed  time  since  last  transition  occurred 
“store”  =  state  variable  that  stores  the  current  input  values 

“overtemp”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  temperature  level 
“overpower”  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
“interruptRespond”  =  flag  variable  set  when  device  is  interrupted  by  an  external  event 
“clickCount”  =  variable  to  store  the  current  number  of  photons  counted  by  the  PNR  SPD 

For  the  controller  we  define: 

Parallel-DEVS  atomic  M=  (Xm,  Ym,  S,  dext,  Sint,  Scon,  to) 

Where: 

Xm  =  {ip,v)  I  p  G  InPorts,  v  G  Xp)  is  the  set  of  input  ports  and  values; 

Ym  =  {{p,v)  I  p  G  OutPorts,  v  G  Yp)  is  the  set  of  output  ports  and  values; 

S  =  set  of  sequential  states; 

Sext  =  2  X  XIj  — 5  is  the  external  state  transition  function; 

Sint  =  S'  ^  S'  is  the  internal  state  transition  function; 

Scon  =  0 X  XIj  Sis  the  confluent  transition  function; 

/I  =  S  ^  T*  is  the  output  function; 

to  =  S  ^  U  00  or  S  ^  R  ,  is  the  time  advance  function; 

Q  :=  {{s,e)  I  5  G  S,  0<  e  <  ta{s)}  is  the  total  set  of  states; 

Xb  =  a  set  of  bags  over  elements  ofX; 

M=  an  atomic  instance  of  P-DEVS. 

DEVS OPMcontroller  {Xm',  S,  Sextt  Sint,  Scon,  1,  to) 
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where 


tp  =  transmission  time  inside  the  eomponent 
temperature  ~  eurrent  temperature  of  the  eomponent 

phase  -  eontrol  state  that  keeps  traek  of  the  internal  phase  of  the  eomponent 
phase  =  {“passive”,  “respond”} 

overtemp  =  flag  variable  set  when  deviee  meets  or  exceeds  damaged  temperature  level 
overpower  =  flag  variable  set  when  device  meets  or  exceeds  damaged  optical  power  level 
clickCount  =  variable  that  holds  the  number  of  photons 

interruptRespond  =  flag  variable  set  when  Respond  phase  is  interrupted  by  an  external  event 

messagebag=  variable  that  stores  the  current  x  input  value(s)  {p,v) 

damage,  temp  =  variable  that  holds  the  component  damaged  temperature  level  parameter 

current  =  variable  that  stores  the  queue  event  being  manipulated 

ctrlOutput  =  variable  that  stores  the  output  control  message  response 

output.port  =  variable  that  holds  the  output  optical  packet  port 

store  =  variable  that  holds  values  of  the  current  input  values 

timeLeftRespond  =  time  left  in  Respond  phase  for  the  current  event 

e  =  elapsed  time  since  last  transition  occurred 

a  =  state  variable  that  holds  the  time  to  next  transition 

ctrlMsgO  =  method  that  generates  a  response  message  to  received  control  messages 
messagebag_lirst()  =  method  that  returns  the  first  element  of  the  message  bag 
remove_event_m()  =  method  that  remove  the  current  (x/,  time  delay,)  from  messagebag 

Every  Sgxt  puts  all  of  its  x  (p,v)  values  into  the  variable  store 

InPorts  =  {“Ctrllni”,  “Ctrlln2”,  “Ctrllnj”,  “Envin”}  with 
Xm  =  {(“Ctrllni”,  Vctri),  (“Ctrlln2”,  Fc/w),  (“Ctrlln3”,  F^r/),  (“Envin”,  Venv)}  is  the  set  of  input 
ports  and  values. 

OutPorts  =  {“CtrlOuti”,  “CtrlOut2”,  “CtrlOuts”}  with 
Ym  =  {(“CtrlOuti”,  Yctriouti),  (“CtrlOut2”,  Y  ctriOuti),  (“CtrlOuts”,  Y  ctriouts))  is  the  set  of  output 
ports  and  values. 

phase  is  a  control  state  used  to  keep  track  of  where  the  full  state  is. 

S=  {phase,  a,  store,  temperature,  overtemp,  overpower,  clickCount  }  =  {{“passive”,  “respond”} 
X  X  FxR  X  {“Y”,  “N”}  X  {“Y”,”N”}  x  F} 

External  Transition  Function: 

dextiphase,  a,  store,  temperature,  overtemp,  overpower,  clickCount  ,e,  ((/7„v,), . . . .  (p„,v„)))  = 
(“respond”,  0,  store,  temperature,  overtemp,  overpower,  clickCount) 
if  phase  =  “passive”  and  p  =  “Ctrllni” 

CtrlOutput  =  ctrlMsg(5tore) 
if  ctrlMsg.status  =  “init”  or  “get  status” 
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outputPort  =  “CtrlOuti” 
if  ctrlMsg.status  =  “set  gate” 
outputPort  =  “CtrlOut2” 
if  CtrlMsg.status  =  “set  port” 
outputPort  =  “CtrlOuts” 

(“passive”,  0,  store,  temperature,  overtemp,  overpower,  clickCount) 
if  phase  =  “passive”  and  p  =  “Ctrllns” 
clickCount  =  messagebag.count 

(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  clickCount) 
if  phase  =  “passive”  and  p  —  “Envin” 
temperature  =  messagebag.temperature 
if  temperature  >  damage.temp 
overtemp  =  “Y” 

{phase,  a  -  e,  store,  temperature,  overtemp,  overpower,  clickCount) 
otherwise; 

Internal  Transition  Function: 

dintiphase,  a,  store,  temperature,  overtemp,  overpower,  clickCount)  = 
(“passive”,  oo,  store,  temperature,  overtemp,  overpower,  clickCount) 
if  phase  =  “respond” 

Confluence  Function: 


dcon{s,  ta{s),  x)  =  SexiSintis),  0,  x); 


Output  Function: 

Xiphase,  a,  store,  temperature,  overtemp,  overpower,  clickCount)  = 
{outputPort,  ctrlOutput) 
if  phase  =  “respond” 

0  (null  output) 
otherwise; 

Time  advance  Function: 

ta{phase,  a,  store,  temperature,  overtemp,  overpower,  clickCount)  =  cr; 

AA.8  0PM  Parallel  DEVS  Code 


Notes: 

•  Assume  that  only  one  environmental  packet  will  arrive  at  any  given  time,  due  to  the  small 
time  scales  involved  and  the  length  of  time  necessary  for  temperature  fluctuations. 
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•  The  component  will  always  reflect  a  portion  of  any  incoming  optical  packet,  regardless  of  the 
environmental  state,  discussions  with  the  optical  SMEs. 

•  If  multiple  optical  packets  arrive  at  the  same  time,  they  will  be  processed  through  the 
reflection  state  as  a  group,  but  then  input  into  the  queue  as  single  entries  with  the  same  delay 
time. 

•  The  reflection  function  always  reflects  the  optical  packet  back  out  the  port  it  arrived  on. 


For  the  0PM  compound  module  we  define: 

Parallel-DEVS  compound N=  {X,  Y,  D,  {Md\AED},  EIC,  EOC,  IQ 
Where: 

X=  {{p,v)  I  p  G  IPorts,  V  G  Xp)  is  the  set  of  input  ports  and  values; 

Y=  {{p,v)  I  p  G  OPorts,  V  G  Yp)  is  the  set  of  output  ports  and  values; 

D  =  set  of  component  names; 

Md  =  {Xd,  Yd,  S,  dext,  Sint,  Scon,  to)  is  a  DEVS  atomic  model; 

Xd  =  {ip,v)  I  p  G  IPorts,  vEXp}-, 

Yd  =  {{p,v)  I  p  G  OPorts,  vEYp}\ 

EIC^  {((V  ipN),{d,ipdy)\  ipN  G  IPorts,  d  E  D,  ipd  E  IportSd}; 

EOC^  {{{d,opd),{N ,opdj)\  opN  G  OPorts,  d  ED,  opd  G  OportSd)', 

IC  c  {((a,opa),{b,ipb))\a,b  G  D,  opa  G  OportSa,  ipb  G  IportSb}', 

{{d,opd),{e,ipd))  G  /^Implies  d ^ e{no  feedback  loops); 

M=  an  atomic  instance  of  P-DEVS. 

N  =  a  compound  instance  of  P-DEVS. 

DEVSopm  =  (X,  Y,  D,  {Md  \  d  ED},  EIC,  EOC,  IQ 

InPorts  =  {“Ctrllni”,  “Ctrlln2”,  “Optlnf’,  “Optini”,  “Envin”} 

X=  {(“Ctrllm”,  v),  (“Ctrlln2”,  v),  (“Optlm”,  v),  (“0ptln2”,  v),  (“Envin”,  v)  \v  E  V} 

OutPorts  =  {“CtrlOuti”,  “CtrlOut2”,  “OptOuti”,  “OptOut2”} 

Y=  {(“CtrlOuti”,  v),  (“CtrlOut2”,  v),  (“OptOuti”,  v),  (“OptOut2”,  v)  \v  E  V} 

D  =  {controller,  switch,  pnrspd,  SMfiberi,  SMfiber2,  SMfibers} 

Md  Mcontroller,  Mgy^dtch,  Mpnrspd,  Mgfdfiberl,  Id^Mfiberl,  MgfdfiberS 

EIC  =  {((V,  “CtrlIni”),(controller,  “Ctrllm”)),  ((V,  “EnvIn”),(controller,  “Envin”)),  {{N, 
“Envln”),(switch,  “Envin”)),  ((V,  “Envln”),(pnrspd,  “Envin”)),  ((V,  “EnvIn”),(SMfiberi, 
“Envin”)),  ((V,  “EnvIn”),(SMfiber2,  “Envin”)),  ((V,  “EnvIn”),(SMfiber3,  “Envin”)),  ((V, 
“OptIni”),(SMfiberi,  “Optlm”)),  ((V,  “OptIn2”),(SMfiber2,  “0ptln2”))} 
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((SMfiber2,  “OptOut2”),(A^,  “OptOut2”))} 

IC=  {((controller,  “CtrlOuts”), (switch,  “Ctrllni”)),  ((switch,  “CtrlOuti”),(controller,  “Ctrllns”)), 
((controller,  “CtrlOut2”),(pnrspd,  “Ctrllni”)),  ((pnrspd,  “CtrlOuti”), (controller,  “Ctrlln2”)), 
((SMfiberi,  “OptOut2”), (switch,  “Optini”)),  ((switch,  “OptOuti”),(SMfiberi,  “OptIn2”)), 
((switch,  “OptOut2”),(SMfiber3,  “Optini”)),  ((SMfiber3,  “OptOuti”),(switch,  “OptIn2”)), 
((switch,  “OptOut3”),(SMfiber2,  “Optini”)),  ((SMfiber2,  “OptOuti”),(switch,  “Optins”)), 
((SMfiber3,  “OptOut2”),(pnrspd,  “Optini”)),  ((pnrspd,  “OptOuti”),(SMfiber3,  “OptIn2”))} 


AA.9  0PM  Controller  Use  Case 


Under  degraded 
temperature  or 
power  threshold 


Over  degraded 
temperature  or 
power  threshold 


^Reflections  are  not  configured  to  be  effected  by  state 
^Electrical  signals  are  not  configured  to  be  effected  by  state 


Figure  242.  Component  states. 
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state  e  {phase,  o,  store,  temperature,  overtemp, 
overpower,  clickCount) 


dint/  go 
Passive 


4«xt  CTRL/ 
create  out 

m»9 


Figure  243.  Controller  phase  transition  diagram 
AA.9.1  Respond  to  a  Reset  Message 

Ineoming  reset  message  arrives  at  the  module  from  the  quantum  eontroller.  Pass  the  message  to 
the  module  eontroller.  Controller  elears  any  stored  variable  values  and  prepares  an 
aeknowledgement  message.  Response  message  is  sent  out  the  appropriate  port. 


•  Identified  Alternative  Uses  Cases 

o  Reaet  to  an  environmental  message 
o  Reaet  to  a  status  request  message 
o  Reaet  to  a  fire  laser  message 

o  Reaet  to  a  elassieal  deteetor  pulse  deteetion  message 


•  Assumptions 

o  Ineoming  eleetrieal  signals  are  not  affeeted  by  eomponent  state 
AA.9.2  Respond  to  Reset  Message  End  Goals 

•  Message  properly  reeeived 

•  Controller  enters  Respond  phase  and  sets  storage  values  to  zero. 

•  Controller  forwards  Reset  Message  to  proper  eomponent(s)  as  neeessary 

•  Aeknowledgement  message  ereated  and  sent  out  the  appropriate  port 

•  Controller  ends  in  Passive  phase 

AA. 9. 3  Respond  to  an  Environmental  Packet 

Environmental  paeket  arrives  at  the  eontroller.  Cheek  to  see  if  environmental  paeket  temperature 
sets  the  eontroller  to  degraded  or  damaged  state.  Cheek  to  see  if  temperature  level  returns 
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controller  from  degraded  state  to  normal  state.  Records  change  in  condition,  if  applicable. 
Change  controller  function  if  in  degraded  or  damaged  state,  if  necessary. 

•  Assumptions 

o  None 

AA.9.4 Respond  to  Environmental  Packet  End  Goals 

•  Environmental  packet  received  properly 

•  Overtemperature  condition  properly  recognized  and  recorded 

•  Change  of  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

AA.9. 5 Respond  to  a  Status  Request  Message 

Status  Request  message  arrives  at  the  module  from  the  quantum  controller.  Module  controller 
prepares  response  message.  Response  message  is  sent  out  the  appropriate  port. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
AA.9.6  Respond  to  Status  Request  End  Goals 

•  Control  message  reeeived  properly 

•  Change  of  condition  or  state  completed  and  recorded  properly,  if  necessary 

•  Change  component  function  properly,  if  necessary 

AA.9. 7 Respond  to  a  Set  Switch  Port  2  Message 

Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  eontroller.  Module  eontroller  passes  control  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
AA. 9. 8 Respond  to  Set  Switch  Port  2  Message  End  Goals 

•  Set  Switch  Port  2  message  reeeived  properly 

•  Message  recognized  and  passed  to  the  proper  component 

AA.9.9 Respond  to  a  Set  Switch  Port  3  Message 
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Incoming  control  message  arrives  at  the  module  from  the  quantum  controller.  Pass  the  message 
to  the  module  controller.  Module  controller  passes  control  message  to  the  proper  component. 

•  Assumptions 

o  Controller  has  completed  initialization  sequence  at  least  once 
AA.  9.10  Respond  to  Set  Switch  Port  SMessage  End  Goals 

•  Set  Switch  Port  3  message  received  properly 

•  Message  recognized  and  passed  to  the  proper  component 

AA.IO  0PM  Module  Use  Cases 
AA.10.1  Respond  to  an  Optical  Packet 

Optical  packet  arrives  at  the  module.  Pass  the  optical  packet  to  the  proper  internal  component. 

•  Assumptions 

o  Reflections  are  not  affeeted  by  module  or  component  state 
AA.IO. 2  Respond  to  Optical  Packet  End  Goals 

•  Optical  packet  sent  to  proper  internal  component 
AA.10.3  Respond  to  an  Environmental  Message 

Environmental  packet  arrives  at  the  module.  Environmental  message  is  passed  to  the  module 
controller  and  eaeh  component  in  the  module. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
AA.10.4  Respond  to  Environmental  Message  End  Goals 

•  Environmental  paeket  received  properly  and  forwarded  to  each  component 

AA.  10.5  Respond  to  a  Con  trol  Message 

Control  message  arrives  at  the  module.  Control  message  is  passed  to  the  module  eontroller. 

•  Assumptions 

o  Incoming  electrical  signals  are  not  affected  by  component  state 
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AA.IO.  6  Respond  to  Environmental  Message  End  Goals 

•  Control  message  reeeived  properly  and  forwarded  to  the  module  eontroller 

AA.ll  0PM  Test  Cases 

Each  coupled  submodule  was  tested  by  sending  messages  to  the  submodule  and  using  the 
operational  graphics  of  the  MS4ME  simulator  to  track  the  progress  of  the  message  through  the 
submodule.  The  primary  purpose  of  the  test  cases  was  testing  the  ability  of  the  coupled 
submodule  to  receive  messages,  pass  them  internally  to  the  submodule  controller  and  pass 
internal  output  to  external  ports.  The  controller  processed  these  input  messages  and  passed  an 
appropriate  message  to  the  controlled  opto-electrical  component.  The  type  of  control  message 
passed  to  each  coupled  submodule  depended  on  the  internal  components. 

•  0PM  submodule  -  control  message  changes  optical  switch  position 

These  test  cases  led  to  iterations  of  testing  and  correction.  Optical  messages  were  tracked 
through  the  internal  components  and  out  the  submodule  output.  Environmental  messages  were 
checked  to  ensure  they  replicated  to  each  internal  component.  All  the  errors  identified  in  the 
coupled  submodules  were  problems  with  coding  the  controllers,  as  the  atomic  components 
functioned  properly  during  coupling. 

Table  4.  Summary  of  Coupled  Submodule  Behavior  Testing. 


total 

tests 

optical 

ports 

Ctrl 

port 

env 

port 

Classical  Pulse  Generator 

4 

0 

3 

1 

Polarization  Modulator 

5 

1 

3 

1 

Decoy  State  Generator 

5 

1 

3 

1 

Classical  To  Quantum 

5 

1 

3 

1 

Optical  Security  Eayer 

4 

1 

2 

1 

Timing  Pulse  Generator 

5 

1 

3 

1 

Optical  Power  Monitor 

5 

1 

3 

1 
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